Re: branching

[David Kastrup]

Mike Solomon <address@hidden> writes:

> I had coffee with a developer a year or so ago who told me that he
> dropped out of the project because of commutation problems with David.
> Last night I wrote to him to share some of these frustrations and he
> wrote back: “as long as David is leading up the team, it’s a lost
> cause, nothing has changed and his way of acting is too problematic,
> independently of his technical excellence.”  I tend to conceive of
> problems in terms of one, two, or many.  The problem here has reached
> the “many" level and I think we need to find a solution that goes
> beyond the individual.  List-etiquette policies, branching policies -
> I’m open to trying anything.

[...]

> What I’d like to see is a situation where David can blow off steam
> however he needs to, he doesn’t feel like people are ignoring him,

You are aware that the above are mutually exclusive?  If people consider
any negative feedback as "blowing off steam", that exactly implies
suggesting to ignore it.

If you take a look at the communications with you that escalated, the
escalation happened _exactly_ because you did not take seriously what
I said.  So I stated my point more strongly.

> and LilyPond can be a dynamic, multiplayer environment without people
> getting offended and leaving the project.

We are currently taking a look at how to create regions of LilyPond that
can be worked on independently and without affecting the overall quality
of LilyPond.  If we manage to do this successfully, we'll be able to
create a community work area where the quality of the individual project
does not impact anybody but the active users of such a project.

I think that a buffer area between "core" or "nothing" will broaden the
base of people casually working on or with LilyPond and exchanging their
experiences.  It will also help with people who say "feature xxx has to
be in LilyPond in order to let me work with application yyy": they or
their tool provider can just drop appropriate files into appropriate
parts of the user- or tool- designated search paths.

If we can get to a consensus that it's best for the project if I'm
thrown out, of course that is perfectly possible.  I would suggest the
end of 2014 as a suitable date, simply because I received forward-going
contributions that I'd prefer to spend as they were intended.  But if
people wish for an earlier date, I'd just pay back a corresponding
amount.

Now regardless of whether I continue participation with the LilyPond
project or not, I definitely think that the code base needs to be
changed to accommodate more independent work.

While tools like git facilitate work based on separate branches and
merges and rebasing, this is essentially negated by a code base where
significant changes will tend to happen all over the place.  This causes
merge conflicts, or even worse, produces inconsistent code since
conflicting changes not touching the same text lines are "merged".

So while the fundamental problem with participating with LilyPond can be
circumscribed as "David does not react gracefully when people step on
his and LilyPond's toes", it does seem to make sense to work towards
more generally available toe room anyway.

In our current developer base, I don't see much more than a theoretical
interest in modularity and usability: many of the developers have become
settled in the status quo which works for them.  Most contributions are
rather focused about creating new functionality rather than making
existing functionality more accessible or even consolidate what we
already have.

There are changes like

commit 38a4081efa4a8ee2f5da780ca0ed2991627afc46
Author: David Kastrup <address@hidden>
Date:   Sun Sep 30 02:21:00 2012 +0200

    Issue 2869: Regularize lyrics lexer mode
    
    That makes lyrics mode rather similar to markup mode regarding how
    words are formed.  {} are never considered part of words unless
    enclosed in quotes.  Unquoted words do not contain whitespace, braces,
    quotes, backslashes, numbers or Scheme expressions.  In addition, they
    cannot start with * . = and | since that would mess with duration,
    assignment and barcheck syntax.  This removes some remaining
    TeX-oriented cruft in the lexer.  The set of word-non-starters might
    need revisiting, but at least the regtests seem to pass.

where a similar change in syntax happened for markups in 2004 if I read
this correctly:

commit 3d04206a83222e89d99ddf1a0766b6b74f158967
Author: Nicolas Sceaux <address@hidden>
Date:   Sun Nov 28 17:50:32 2004 +0000

    * lily/parser.yy: get rid off < > in markups by treating { } as
    real lists.
    
    * lily/lexer.ll: remove < > from markup lexer mode.

This change was cited as a typical nuisance for newcomers on a list
counted off the head of one user recently (he was surprised that it was
actually fixed by now, now meaning 2.17.4).  There are a number of other
long-standing problems and awkwardnesses that I occasionally stumble
upon: why haven't things like the \tuplet command not been provided
years ago?

One answer, of course, may be that this rather obvious name might well
be expected to be already in use by user-defined functions, so making it
a reserved word like \times was once may break existing documents.  Now
that it could be implemented as a function itself, this concern is only
valid when applying convert-ly (which would create uses of \tuplet in a
document previously using \times).

It could probably be useful to mark some conversions in convert-ly as
"optional": meaning that they may improve the look of old sources but
are not necessary for retaining the meaning.

Now if we are taking a look at the LilyPond infrastructure, it's safe to
say that I am not unilaterally responsible for its downfall: the Mutopia
site has more or less become inactive and its mailing list dormant.
I doubt that this can really be attributed to my bad influence.

It's also worth noting that LilyPond development was ailing when
I started actively contributing.  The first major fallouts of me on the
list happened when repeatedly contributions of mine were simply ignored
and dropped through the floor without review or consideration.

Since then, Graham established the infrastructure and recruited the
workers necessary for making sure that even with a minimally active
and/or interested developer base, the contributions of newcomers will
not get lost silently.  As opposed to me, Graham excelled at organizing
and maintaining community efforts like this which makes his leaving an
even larger loss.

At any rate, I do see the necessity for reworking the code base of
LilyPond in a manner that better encapsulates functionality in fewer
places as a prerequisite of having more work on LilyPond happen without
endangering its long-term viability as stable software.

And I see no-one in the current developer base who would work in that
direction.  Without such changes, LilyPond will remain usefully workable
code for only a small upper bound to the ddeveloper*irritability*dt
integral.

So I do see an advantage for the time after my participation in LilyPond
if I don't stop just now.

-- 
David Kastrup