|| ||Lennart Poettering <mzerqung-AT-0pointer.de> |
|| ||Development discussions related to Fedora <devel-AT-lists.fedoraproject.org> |
|| ||Re: Rawhide boot problems |
|| ||Mon, 10 Sep 2012 22:30:41 +0200|
|| ||Article, Thread
On Mon, 10.09.12 14:09, Bill Nottingham (firstname.lastname@example.org) wrote:
> Matthias Clasen (email@example.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
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 Poettering - Red Hat, Inc.
devel mailing list
to post comments)