On Wed, Jun 19, 2019 at 10:29 AM Vít Ondruch <vondruch@xxxxxxxxxx> wrote: > > > Dne 18. 06. 19 v 16:54 Aleksandra Fedorova napsal(a): > > On Tue, Jun 18, 2019 at 1:31 PM Neal Gompa <ngompa13@xxxxxxxxx> wrote: > >> On Tue, Jun 18, 2019 at 5: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. > >>> > >> I think this is the first time I've heard a coherent description of > >> the intent of this stuff. If it really is intended to work this way, > >> it'd be very helpful. > >> > >>>>>> 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. > >>> > >> I think you kind of missed what I was asking: I want side tags that > >> are composed entirely of scratch builds. The result *must not* be used > >> to merge into the distribution. It *must* be thrown away and when the > >> pull request (or whatever) is merged, it should trigger the build > >> again, which would be a "real" side tag that would get auto-merged on > >> success. > > You are right, I missed that part. And I agree this is needed. But I > > am not sure if there is already a proposal for that. > > > > There are several ways how one can implement it. I would personally > > prefer pull requests to dist-git over scratch builds. I think it is > > important to keep some visibility in the system, so that not just the > > owner of a change, but also random lurkers can see what is being > > prepared. (Also solves the ) > > > > And if we look into PR-based workflows, then Zuul team has a proof of > > concept pipeline which builds packages on PR in Pagure. > > Which is not your ordinary Jenkins PR-triggered pipeline. > > > > The killer-feature of Zuul > > > Zuul team? Zuul feature? I am probably missing some context ... > > It does not look like you are talking about > https://github.com/Netflix/zuul which is the first reference to Zuul > returned by Google. Yes, for me the OpenStack's Zuul is the default one :) Project: https://zuul-ci.org/ It comes from OpenStack Infrastructure as an attempt to replace Jenkins with smth scalable. Fedora-related work https://fedoraproject.org/wiki/Zuul-based-ci -- Aleksandra bookwar > > Vít > > > > is that it can manage cross-project > > dependencies. It understands links between pull-requests in different > > git repositories, even in different Git forges (Pagure and GitHub for > > example). > > > > If, let's say, you mark PR#123 in rpms/dnf as dependent on PR#765 in > > rpms/rpm. Zuul fetches source code for both projects into the > > workspace, and runs the pipeline in this workspace. Results of the > > pipeline will be applied to both PR's. > > Zuul could also do the merges for you, then it will also ensure that > > the chain merge of dependent patches happen in the right order. > > > > I like this concept, and I wonder if we can map this workflow cleanly > > on the sidetag process, which happens after code is merged in > > dist-git. > > > >> This is more or less the equivalent of a staging/integration overlay > >> that is used to test, where the artifacts are not preserved because > >> they aren't useful beyond that. > > _______________________________________________ > > 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
