On 09/10/2012 08:35 PM, Matthias Clasen wrote:
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.
Well the theory is, all major development should've already landed in
rawhide before the time of the mass-branch. When that happens the
current setup works smooth as peaches. But rare upstream projects march
to Fedora schedules, so you either delay feature/version X to the next
Fedora version, introducing it in rawhide right after the mass-branch.
Or fight with the branching. And because everybody wants to squeeze in
the latest XYZ to this version already so... For example GNOME is AFAICT
some two months off the "perfect" alignment.
Me thinks flexibility with the branching-point would help: branching
before alpha is far too early for many projects, for others its
absolutely necessary. It all depends on what happens to be going on with
a given package / package set on a given cycle, one size fits almost
everybody poorly.
In the "squeeze" cycles, what I always end up missing most is having
rawhide and "branched" to share the same git (master) branch, but
different builds (as you never know what *else* might change on rawhide
- binary package inheritance doesn't work well either way) deep in to
the release cycle (at least up until beta). Of course syncing from
rawhide -> branched is no longer root-canal painful with git, merely
tedious, but tedious enough that many packagers dont bother, so we end
up having this (IMO) twisted situation where active development goes on
in a branch and master lags behind. And inevitably bits and patches fall
through the cracks when active working moves back to master. Seen my
share of it.
- Panu -
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
