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?
Thanks,
Pierre