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@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
