Rawhide boot problems

[Panu Matilainen]

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 -