unfrozen repo somewhere?

[Ralf Corsepius]

On Sun, 2008-09-28 at 23:51 -0400, Tom Lane wrote:
> "Horst H. von Brand" <vonbrand at inf.utfsm.cl> writes:
> > Ralf Corsepius <rc040203 at freenet.de> wrote:
> >> Decouple "product development" (here: FC<N+1>) development from bleeding
> >> edge "unstable/experimental" "head development" (here: rawhide).
> 
> > Needs more hands. Starves the "product development" of developers and
> > testers. Was the idea in Linux before 2.6, was abandoned for exactly the
> > above reasons.
> 
> Yeah ... when it's time to ship a release, you need a forcing function
> to encourage people to test-and-fix-bugs, rather than develop-cool-new-
> features.
Correct.

>   Branching early encourages people to ignore the release and
> do the latter.
Well, I don't agree. 

IMO, branching encourages "early adopter end-users to try sneak
previews" and to stay away from the "bleeding edge aiming at
developers".

> The Postgres project has generally avoided early branching, and I
think
> that policy has been a significant contributor to our ten-year history
> of making stable releases.
> 
> Branching early works if you have a sufficiently large critical mass of
> developers and testers who like to work on stabilizing a release, and
> another sufficiently large critical mass of people who prefer to work
> on pushing new features forward, plus enough extra manpower to deal with
> keeping the two branches in sync.  If you lack any of those things it's
> a loser.
> 
> There are certainly a small number of open source projects that have
> enough popularity and enough ensuing manpower-and-expertise to make a go
> of this approach.
Small number of projects? Probably a matter of perspective ;)

>   To imagine that it's workable for the majority of
> projects is to demonstrate lack of connection to reality.
Pardon, but you probably can relate, why I have to disagree on this. 

I would turn this argument around: The apparent lack of quality of the
distro, the amount of bureaucracy and ineffectiveness the Fedora
approach cause are a living proof for a non-functional approach.

Ralf