Branching policy (was: My resignation)

Richard Rogers rprogers at
Tue Jul 13 12:41:03 PDT 2004

On Mon Jul 12 16:35:04 MDT 2004, Jeremy Utley wrote:

> The core problem is the LFS community has become fragmented into 2 
> different camps.  For want of a better description, I'll use 2 examples, 
> and please noone take offense at how I describe this!
> 1) The Jeroen/Archaic camp - Slower developement, making sure that 
> things are always stable, even if we're not leading the pack in 
> incorporating new things
> 2) The BE-LFS camp - Fast development, working with bleeding edge (Beta 
> releases, sometimes CVS code).
> This fragmentation is what was supposed to be resolved by the 3-tier 
> development model, but the frustration still remains from previous.  

I think the oddness of the subject is symptomatic of the problem :)

The fragmentation is a political problem. A technical tool like
CVS (or SVN, or whatever) is not going to give you much leverage
for solving it.

The current (ill-defined, at least as far as I can tell) branching
policy doesn't make much sense to me. It struck me more as forking
the project, and you've hit on exactly why.

If the fast dev camp commits a bunch of bleeding edge stuff on
"their branch," the slow camp can't simply "merge the blood out."
Branching and merging are not magic, no matter how simple the
revision control system makes the commands.

For branching and merging to work requires A LOT of COORDINATION.
Everybody has to be following the same development roadmap, and
put some thought and COMMUNICATION into what and when to branch
or merge. The current policy doesn't seem to address that at all,
at least as far as I can tell...

If we're going to have "camps," they need to fight it out at
the roadmap level. Whichever loses has to be the loyal opposition
when it comes to following the revision control policy. There
are probably better ways to solve the problem though.

One of the benefits that braching affords you is the ability
to continue active development while a frozen code base is
stabilized for release. It does NOT afford you the ability
to tollerate developers trying to take the code base in
different directions. Nor does it relieve you from the responsibility
of release planning. In fact, it increases that burden.

I'll stop whinging now :)

 - Richard

More information about the lfs-dev mailing list