Rawhide boot problems

Lennart Poettering mzerqung at 0pointer.de
Mon Sep 10 20:30:41 UTC 2012


On Mon, 10.09.12 14:09, Bill Nottingham (notting at redhat.com) wrote:

> Matthias Clasen (mclasen at redhat.com) said: 
> > On Fri, 2012-09-07 at 11:54 -0700, Jesse Keating wrote:
> > 
> > > Fedora 18 is basically closed for new feature work, and instead the 
> > > focus needs to be on integration of the existing feature set and 
> > > bugfixes.  But as you state there is a large amount of time before F18 
> > > releases, which means new feature work would have to stall out for 
> > > months.  Instead, new feature work can begin for F19 and get ahead of 
> > > the game.  That's why F18 and F19 are divergent.  That's why we went 
> > > from a single line of development to two.
> > 
> > But we are not doing two lines of development in systemd or GNOME or
> > other upstream projects. So, why again should we build the same stuff
> > twice ? I personally just don't have the time.
> 
> Honestly, the problem here doesn't really come from a model of building
> for both, or only building for branched, as both are valid strategies
> for a maintainer to take.
> 
> The problem came from a well-intentioned packager who happened to
> choose one strategy when applying a fix, when the maintainers prefer the
> other. I'm not sure how to avoid this other than having each package
> speficy which it prefers (kind of messy) vs. mandating a particular style.

To deal with this I added a small message to the systemd .spec file that
explains this. I do hope that people will actually read it before
commiting things.

Anway, I still believe that the default approach to doing package
development should be to focus on F18 as long as it isn't released, and
only open F19 for a packge if the packager decides he is ready to. Right
now we have the opposite where a package immediately is branched twice
and packagers then have to make sure nobody uses the newer branch yet.

So yeah, I do acknowledge that both modes of working make sense, I just
believe the default approach should be one where focus is on stabilizing
things, not on developing new stuff all the time.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.


More information about the devel mailing list