On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote: > Hi, > > On Fri, 2018-03-09 at 11:35 -0800, Kevin Fenzi wrote: > > Sure, with this proposal you would: > > > > * request a side tag > > * build a, wait for it to be added to the repo, build b, etc. > > You would not need to file overrides, just build them in the right > > order with wait-repo between them. > > well, it's not better, it's worse. I could not just run one command and > let the computers do the task on their own, I just check from time to > time whether anything broken, but I'd be supposed to babysit whole > build process with the packages from the "chain-build"? That's truly > worse, needs more of my time, while the koji can do it on its own. > Computers are here to help people, right? :) Tooling can be built no? Why do you assume we can't make chain-build work with side-tags? Is there a technical reason we can't just have the tool submit a build, wait for the new repo, submit the second build and so on? If whether this needs to be a `chain-build --side-tag=<foo>` or a `side-build <foo>...` is up for discussion :) > > I'd like to see a 'no new broken deps' test/check... but we could > > change the tests over time. > > Yeah, that's it, without such test you just make obstacles to packagers > with no gain at all (if broken deps are recognized only after pushing > the side tag into the Rawhide, then it's really only about unneeded > obstacles). The side tags would only be used if you need to update multiple packages, so having the test run while you're in the middle of it and thus you know it's not going to pass, seems a little useless no? Seems to me much more interesting to say: I have a few packages to update, let's update them, ok I'm done, could you check if I missed any? yes -> fix, no -> merge > > You request a side tag, > > Who is going to respond to it? The idea has been submitted a few times already in this thread, the side tags would be managed in bodhi very much like buildroot overrides are currently. > Will it be automated, with no specific people being involved? It would be automated via bodhi, likely have a rather short life by default (exactly to avoid the race-condition issue that Kevin Kofler mentioned in another email) but that life period could be expanded for larger rebuilds. > (if I recall my college study properly), how you'd like to synchronize > the process between people in various countries and time zones in > practice, while limiting the delay to a minimum? How would this be different from today? If it takes a week to solve a rebuild today, the side tag tomorrow would remain open for a week. The difference is that during that week, we will still be able to compose rawhide tomorrow (and thus test all the other changes), while we can't today. > > > That's also another disadvantage of the gating. I recall seeing > > > broken dependencies messages for package I've no commit rights for > > > for weeks. > > > > Yep. Or longer. > > Definitely, and it's the main point against gating Rawhide. If people > cannot react in the timely manner right now, with already working > infrastructure, how is the gating going to help and address this > problem at the first place? Because that problem will remain isolated from the rest of the distro. So yes, as you're pointing out below some package will get a little behind and others won't. But the formers won't prevent testing/integrating the laters. > The gating will help to have buildable composes all the time. That's > its main purpose, right? Then it'll help with what? What is it good for > to have buildable composes, when they are using outdated software? All > the QA work will be wasted on those composes, because of delay of some > package update due to the gating. > > > You could ask for commit on those packages you need commit on. > > If those maintainers don't approve it, ask for unresponsive > > maintainer process and you will get commit rights. > > Maybe they have a reason why they want to have as less people on the > package as they can. Or they can miss some notification from "pkgdb" (I > know, it's not pkgdb these days) or have it lost in the spam folder... > And it's a bad idea to expect that other people have time to work on > Fedora just at the moment when I decide to push in some giant API It seems to me this is even worth today. You decide a giant API change, the other people don't have time to work on Fedora just at that moment, the entire Fedora is stuck because things are burning. Tomorrow: you decide a giant API change, the other people don't have time to work on Fedora just at that moment: the rest of Fedora is happily moving forward. Yes your change will be delayed in its integration, but it won't delay or impact other integrations. > change, not talking that many of the packagers just do "proxies" for > upstream, they possibly never touched the upstream code to be able to > fix anything in the code, thus they rely on response from the upstream, > which can add even more delay in some cases. Not talking that > unresponsive maintainer process should be started only after some time > of inactivity of the package maintainer. > > It's been a long trail of things that needed to get worked out. > > it has nothing to do with availability. A number of people have been > > spending lots of time fixing things. > > I see, that's understandable. How is rawhide gating going to help with > this in practice? Because if the packager want to push their update, they will need to investigate why it's not passing the tests, not infra. So in theory Kevin Fenzi would not have to dig into systemd just before freeze to find out what changed and broke the world. The systemd maintainer (with help if necessary, of course) would. So that'd be handling back the issue to the expert on the package, the maintainer rather than the infrastructure or releng folks trying to get a compose out. > (Search for 'outdated software' above.) There will be > still needed some people looking into the issue and spend their time on > it, maybe they will be in less pressure, but I'm afraid it'll be just a > feeling. Nobody should expect infrastructure folks understand each > package (like you mentioned systemd here), at least I do not expect it, > thus I'd expect you had some coordination with systemd package > maintainer and its upstream to find out the root cause of the problem. > Was it any smooth? Did it even happen? Might each maintainer of a crit- > path package (or a package which has some users (libraries)) do the > same round trip as you did for the last week? Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
