On Tue, Mar 06, 2018 at 03:33:44PM +0100, Kevin Kofler wrote:
> Pierre-Yves Chibon wrote:
> > On Sat, Mar 03, 2018 at 07:35:00PM +0100, Kevin Kofler wrote:
> >> So please let us just repeal that "Rawhide can never go backwards"
> >> policy.
> > This is actually a fair point, but I wonder what prevents us from doing it
> > today.
> Technically, nothing. This is purely a policy issue.
I'd be curious if there isn't more than just this, or if someone remembers why
that policy was created.
> > The only thing I can think of is that we have no mechanism to choose what
> > goes in rawhide and what does not, from the moment you build it, it will
> > go into rawhide.
> > So maybe gating rawhide, would give us that mechanism to a) prevent
> > package we know are broken from entering rawhide, b) potentially remove
> > from rawhide package we later find are breaking things.
> "b)" can be done without any gating. That's what koji untag-pkg is for.
I suspect there is an ACL question here (which may be one of the reasons why the
policy was put in place).
> > I guess another issue with removing something from rawhide is that
> > something else may have been built on the top of it, thus removing A would
> > imply, automatically rebuilding B, and C, and D...
> That would have to happen anyway, even if you bump Epoch to revert A as is
> the policy now.
Fair, would be nice to have a way to do that automatically though :)
Maybe, we should only allow removing builds from rawhide for a limited period of
time and when that happens, just rebuild everything that has been built since
the build being removed happened.
There is a need for some tooling there to make it comfortable for all of us, but
we would need to map out carefully the requirements.
I'm not entirely sure I can commit on writing the tool right now, but would you
be willing to help mapping out the requirements this tool would have?
devel mailing list -- firstname.lastname@example.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org