Hi, On Mon, 2018-03-12 at 12:10 +0100, Pierre-Yves Chibon wrote: > On Mon, Mar 12, 2018 at 11:33:36AM +0100, Milan Crha wrote: > > 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. > > > Tooling can be built no? Why do you assume we can't make chain-build > work with side-tags? That wasn't my suggestion, that's what Kevin Fenzi suggested and I sort of questioned it. :) > 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 Yes, definitely. How that "checked if I missed any" question will be implemented is important. It's necessary to have it done before merging the side tag, otherwise there will be no gain in gating at all, right? The best time is to have done the final check automatically when the merge of the side tag is requested, if I understand it correctly. > The idea has been submitted a few times already in this thread,... Oh, right, I'm sorry for repeating it. My fault. > 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. I see, that makes perfect sense. Some packages won't stop the rest of the distribution. I'm only afraid people will care less when the problem will be in a side tag, rather than in the main stream. > Because if the packager want to push their update, they will need to > investigate why it's not passing the tests, not infra. Definitely, that's my point too. I'd expect it working that way already, with or without gating. People should be responsible for changes they do in their packages (generally speaking, I do not mean any offense to systemd folks, not talking that I can imagine that finding such kind of bugs is a nightmare even for the developers of the software). Thanks and bye, Milan _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
