Mike Solomon <address@hidden> writes:
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 this is an excellent goal.
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.
I agree.
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.
This seems like a rather extreme, all-or-nothing solution.
What I’d like is people reacting gracefully when they feel that their toes are stepped on.
There was one time when I started with the project where I blew up at Han Wen for pushing a major change with minimal review on a large scale beam collision project that I was working on. I flipped out - it was 80ish hours of my work down the toilet. I was not at all considerate in what I said and Han Wen dropped out of the project for a while. I’m not sure if the two were linked, but I felt _terrible_ about this - I realized that this is _never_ appropriate or useful for LilyPond, or for anything, to have communication like this.
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.
I completely agree.
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.
Stepping on LilyPond’s toes is in the eye of the developer - what you consider stepping on LilyPond’s toes may not be for someone else and vice-versa. All of us are LilyPond’s toes.
I agree that it makes sens to work towards more toe room. I don’t think this alone will make LilyPond viable in the long run.
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:
You’re not unilaterally responsible. Life happens, people take time off, new people come.
It is alarming, however, how much over the past few years the commit diversity of LilyPond has gone down. I think communication issues are the biggest player in this.
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.
No, this is not.
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.
The bad old days were bad, I agree. No one (including me) liked the lack of review, but I don’t think this justified the fallouts back then either.
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.
His leaving is a huge loss, and as he has stated several times, one big reason is the lack of sense of community. devel-list quarrels and the thaws that come from them have real impacts on LilyPond - I can’t emphasize enough that we need to stop marginalizing this issue and tackle it head on. My solution was no better than anyone else’s for a while - I, like others, just dropped out. But that’s no good - we have to find a solution. Modularity, while perhaps a good long term solution, is a long ways away. How are we going to deal with this in 2014?
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.
I completely agree.
And I see no-one in the current developer base who would work in that
direction.
One of my major projects - eliminating calls to translate_axis, was moving exactly towards this (
https://codereview.appspot.com/7185044/). The less we’re calling translate_axis (the Defense Against the Dark Arts function of LilyPond) in the backend, the more we can isolate functionality to certain places and the less surprises there are.
I’ve for the time being dropped it until we can work out these community problems.
Without such changes, LilyPond will remain usefully workable
code for only a small upper bound to the ddeveloper*irritability*dt
integral.
I agree.
So I do see an advantage for the time after my participation in LilyPond
if I don't stop just now.
Everything you do will be advantageous for your time in and after LilyPond.