Mike Solomon <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 _______________________________________________ lilypond-devel mailing list [email protected] https://lists.gnu.org/mailman/listinfo/lilypond-devel
