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