Re: Frequently broken Rawhide/Branched composes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux