Re: branching

[Carl Sorensen]

On 12/10/13 5:42 AM, "Mike Solomon" <address@hidden> wrote:

>Hey all,
>
>As 2.18 draws near, I¹d like to work with everyone to establish a system
>of branching for LilyPond development.  After several rounds of
>discussing things with David K, this emerged as the best way to avoid
>arguments about integrating work into the development branch that have
>led several contributors, including myself, to significantly reduce time
>on the project. 

I can see how the proposed mechanism avoids arguments about work that is
going into individual developers branches, but I don't see how this avoids
arguments about what goes into the development branch.

As far as I can see, this proposal supports the creation of multiple forks
of the lilypond development branch, one for each of the "privileged"
developers, plus one for the accepted features.  And then lilypond.org
should support all of those forks.

This seems like a nightmare to me.  It is good for somebody who wants to
get their features out the the user base.  But this just makes the
decisions about what to include in the development branch more emotionally
charged.  I'll present a hypothetical exchange between two caricatures:
the creative developer who is only concerned about adding a really neat
feature, and doesn't care how it affects the code base; and the consistent
developer who is only concerned about the consistency of the code base,
and would rather have no new features added than have a new feature added
that requires contortions in the syntax, the parser/lexer, or the code
base.  Note that both of these are caricatures, drawn for the purpose of
highlighting the conflict, not for the purpose of illustrating the
behavior of any real developer.

Creative developer: "See how many people like this feature?  It's so
positive that we absolutely have to include it."

Consistent developer: "See how badly this would destroy the current code
base?  It's just an ugly hack.  If we accept features like this, our code
base will soon consist of nothing but ugly hacks.  I don't care how many
people like the feature; it's disastrous as currently implemented, so I
won't accept it."

And now, in addition to the different points of view of these developers,
we have the added pressure of users clamoring for a feature.

Personally, I want *both* the creative developer and the consistent
developer to be satisfied.  I want ugly hacks in the codebase to be
decreasing, not increasing.  I want new features that make the engraving
better.  If we can't implement new features without ugly hacks, I don't
think they should be added to the codebase.  But I don't want stasis in
the codebase to prevent the addition of new features.

Developers already have branches on the main repository.  So this proposal
is not really to add branches.

The real issue in the proposal is about how to get users using these
branches.  I have a very hard time thinking that it's in the best interest
of lilypond as a project to have multiple official development branches.
Instead, I think that developers who create a branch that provides some
new functionality should invite users to test the branch (which probably
means that the developer needs to get GUB running on his or her branch and
then make the binaries available).


>[1]  I feel that this reduction in commit diversity is the biggest
>obstacle to LilyPond¹s future evolution, which is why I¹m calling on
>everyone to make a concerted effort to think this through.


I have made a concerted effort to think this through. I believe that a
reduction in commit diversity is a serious problem.  I think the community
was greatly weakened when Mike felt that it was no longer worth putting up
with the hassles to make his contributions.

However, I think that a fractured development branch (up to 6 different
branches) would be an even bigger obstacle to future evolution.  I think
it would lead to a balkanization of LilyPond.

Of course, given my participation in development over the last couple of
years, my input may not be worth much.

Thanks,

Carl S.