Rawhide boot problems

Kevin Fenzi kevin at scrye.com
Sat Sep 8 01:43:32 UTC 2012

On Sat, 8 Sep 2012 01:32:55 +0100
Matthew Garrett <mjg59 at srcf.ucam.org> wrote:

> On Sat, Sep 08, 2012 at 01:28:53AM +0100, Matthew Garrett wrote:
> > Sure, and that's clearly the behaviour that Lennart wanted as well.
> > But instead there was a mass rebuild that bumped his rawhide nvr
> > and now he needs to do rawhide work manually. If development should
> > be happening in rawhide then why is rawhide inheriting from f18?
> I should clarify that. If there's still feature development then
> clearly that should happen in rawhide. But if the maintainer is
> working on stabalisation in f18 then rawhide should still get those
> packages. Right now what happens is that that's absolutely fine right
> up until someone decides to do a mass rebuild and suddenly the
> maintainer has to do active development in rawhide at the same time
> as they're trying to stabalise f18. That doesn't seem optimal.

This actually has nothing to do with mass rebuilds (unless I am
misunderstanding). Mass rebuilds are done _before_ branching to avoid
problems like this. :) 

In this case a proven packager noticed an issue in systemd, fixed it in
rawhide. That breaks inheritence, so it will now always need builds in
rawhide, it will not inherit from f18. 

We have discussed this before, and probibly will again. ;)

During freezes (like the especially long one we have right now) this is
especially painfull for rawhide, as fewer packages come in and they
have to wait for the freeze to be over to get updates for non release
blocking issues. 

It's a balancing act I fear, nothing will make everyone happy. 

Inheriting from updates-testing means rawhide can and will 'go
backwards' as updates get unpushed/dropped. Dropping inheritance
entirely means more work for maintainers. 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/devel/attachments/20120907/e7e0dea1/attachment.sig>

More information about the devel mailing list