On Sun, 2008-09-28 at 23:51 -0400, Tom Lane wrote:
"Horst H. von Brand" <vonbrand(a)inf.utfsm.cl> writes:
> Ralf Corsepius <rc040203(a)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