On Tue, Jun 18, 2019 at 11:21 AM Aleksandra Fedorova <alpha@xxxxxxxxxxxx> wrote: > > Hi, > On Tue, Jun 18, 2019 at 3:05 AM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > > > On Mon, Jun 17, 2019 at 8:53 PM Kevin Fenzi <kevin@xxxxxxxxx> wrote: > > > > > > On 6/17/19 4:47 PM, Kevin Kofler wrote: > > > > Kevin Fenzi wrote: > > > >> I disagree. I think we need gating to block as much stuff that breaks > > > >> things from landing as we can and then we should find that keeping > > > >> composes going is much easier on all of us. Then things can be fixed > > > >> when gating catches them and it's on the person who broke things. > > > > > > > > And that is going to make development completely cringe to a halt. It is the > > > > nature of a distribution branch under development that things will sometimes > > > > be completely broken for a couple weeks. There needs to be a place to do > > > > development that can cause such temporary breakage. > > > > > > I again completely disagree. There is no reason for weeks of breakage. > > > Most of the issues that break composes are unannounced abi bumps where > > > just rebuilding dependent packages fixes it. Or broken deps (likewise). > > > Or mistakes made in kickstarts/comps. Or something that doesn't even > > > run. What good does having everyone broken for weeks do? > > > > > > > And that comes down to people shouldn't need to have to think about > > these things when working in Rawhide. While I don't disagree that > > Rawhide should be usable, I fundamentally disagree with making it > > harder for people to put things in Rawhide. We should be developing > > our tooling to make it _easier_ for stuff to go into Rawhide, and have > > Rawhide fix itself when the issues are relatively trivial to fix (such > > as reverse dependency rebuilding). > > I think this is exactly what gating is supposed to do. > > Let's compare it in this way: > > currently to add a feature which may break Rawhide and some unknown > dependencies of the component you need to write a HEADS-UP e-mail, or, > better, submit a Change request with the analysis of the change. > People who read this e-mail would need to make a guess on whether or > not his change affects them, then they have to fetch it and test it > somehow, then they have to provide the feedback back to you. You need > to wait for feedback, then you get the reports, in best cases - bugs, > which you need to debug, requesting more info. Then you implement the > change, hit the unexpected bug, which was unnoticed, and block others > from building their packages and implementing their changes for > unknown amount of time. > > With gating you can submit a code change, the tooling will take care > of building it, building its dependencies, informing you of possible > breakages, giving you the list of actual issues with all the debug > logs. And then based on this data you can proceed or stop and rework > the change a bit more in collaboration with exactly those people > affected. > > I also think that we need a second point of view here: you were > talking about not driving away the developer, who makes the change. > But there are also other people who we shouldn't drive away. For > example developers who depend on the change. Or QA who need to react > on such changes. These people are have their part in the process. > > > But, to be honest, I think there is a bit of overreacting on the > entire Gating topic. > > It doesn't do a hard block. It is included in the design that gating > can be bypassed. But it supposed to provide better analysis of the > change. Bypassing of the gate can happen, The key here is that it > won't be a surprise, rather informed decision. > > > > > The side tag approach already does not scale, as evidenced by this thread. > > > > > > It does. You just need to communicate with others working in the same > > > area, IMHO. I don't think we need some technical thing for something > > > that happens rarely and can be solved by more communication. > > > > > > > Side tags will happen a lot more often because the tooling is pushing > > us to do it that way. Don't discount the potential for future > > insanity. I'm still not sure side-tags are enough. Could we have a > > concept of a "scratch side tag"? Something like a scratch build, but > > contains a collection of builds and creates an overlay repo that can > > be used to run checks on for auto-merging? If they're good, then it > > would get auto-built properly into the main rawhide tag (or even > > stable tag!). > > Afaik, this is exactly the concept of a dynamic sidetag as Fedora > Infra is currently implementing. Sidetag in koji as a sort of > pull-request: you create sidetag, get repos and composes built out of > it, run tests, get results. Then "merge" this sidetag into the main > repo. > > And while clashing sidetags is a problem, it is the same problem as it > happens with overlapping pull-requests when several people are working > on the source code. > > There are several ways to address it: > > 1) create smaller pull-requests and merge them more often > > This is one of the core points of CI workflows and it also seems to be > most often underestimated. There is an overhead in creating smaller > changes, which we are trying to address with tooling. But the overhead > is _linear_. While the complexity of one merge grows exponentially > with the size of the branch you are merging. > > The smaller the changes - the easier the rebase. > > 2) reorganize the codebase > > When working with source code, it usually means splitting files. If > there are many changes targeting the same file again and again, > causing conflicts, it might mean this file has too much logic bundled > in it and needs a split up. > > It might also be merging files. For example if there are many changes > targeting two files and it causes problems when these two files get > out of sync. > > When applied to RPM packages, it may be also a good question: if there > is circular dependency between packages, so that these are strictly > tied to each other by version and can only be processed together - why > these are separate packages and not subpackages? > > 3) Talk about changes in advance > > This of course is the default, and it doesn't go anywhere with gating > or without it. Again I believe gating can make it easier. For example, > we can add a note on conflicting "pull-requests" and put a rebase > requirement as a gating check. This was the most coherent argument on this topic I've read so far. While I don't agree with all the points, the three points outlined above are pretty on point, IMO. Thank you. Fabio > > > > > > -- > > 真実はいつも一つ！/ Always, there's only one truth! > > _______________________________________________ > > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
