On Mon, Mar 12, 2018 at 12:48:02PM +0100, Milan Crha wrote: > 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 way I envision this would be: you request the side tag to be merged, the test will be run, report its outcome to you. If the outcome is positive (the test passed) it will automatically merge the tag, and otherwise it won't touch the tag, giving you the opportunity to fix the issue. Does that sound right? > > 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. I guess that could happen, but on the other side, since the problem is isolated in a side-tag it's not in the main stream and thus not available, even to the people who started working on this. Pierre _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
