On Dec 11, 2013, at 11:36 AM, David Kastrup <d...@gnu.org> wrote:
> Mike Solomon <m...@mikesolomon.org> 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 <d...@gnu.org>
> 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 <nicolas.sce...@free.fr>
> 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.
Cheers,
MS
_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
