Re: a thank you :)

[David Kastrup]

"Karol Majewski" <address@hidden> writes:

> Yeah... just imagine where would be LilyPond without David.... we
> would probably still use 2.12 ;)

Not all that likely.  2.14 has had all in all 43 commits of me.
Basically I rewrote define-markup-commands (and obliterated
define-internal-markup-commands), worked on harp-pedals (definitely the
kind of work that only gets done because of joining a preceding
discussion since I don't have an actual clue about either harps or
pedals).

It's probably sobering that those include

      lily/stem-engraver.cc: allow distinguishable durations to be stemmed 
together (string chords)
      lily/stem-engraver.cc: Improve error message for incompatible durations 
while stemming
      stem-engraver.cc: recreate stem if in need of change when merging 
different heads
      Issue 1471: Invalidate alterations upon key change rather than forgetting 
them.
      scm/music-functions.scm: Let booleans be booleans.
      Revert "Issue 1471: Invalidate alterations upon key change rather than 
forgetting them."
      Revert "stem-engraver.cc: recreate stem if in need of change when merging 
different heads"
      Revert "lily/stem-engraver.cc: Improve error message for incompatible 
durations while stemming"
      Revert "lily/stem-engraver.cc: allow distinguishable durations to be 
stemmed together (string chords)"


Namely material that has been accidentally pushed and reverted.  It
turns out that string chords are not properly implemented even now.
I've lost my own repository since then but it's not likely that the
state of those reverted patches has been sufficiently satisfactory.

2.16.0 was released with 10 times the patches from me in it from a
gathering of close to 20 developers and users in my house, marking a
highlight in the excitement of working on LilyPond.

2.18 was again a solid step forwards even though taking longer than
desired.  In the start of 2014, I got distracted into fixing serious
performance issues with "git-blame", a development tool of marginal
interest to LilyPond developers as part of the Git version control
system.  I got mostly dragged into it because I do all my work with
Emacs, and work on Emacs is also slated to move to Git "real soon now".

This work had taken months of my focus on LilyPond, embarrassing me
enough to stop sending out my more-or-less monthly reports to my
financial backers.  I'll probably summarize the resulting hit of both my
work on LilyPond as well as my financial situation soon.  After skipping
on my blood pressure medication (the medication also impacts my
productivity), I had to get hospitalized for a week, turning myself in
with stroke-like systems and a blood pressure of 250/130.

At any rate, between 2.18.0 and now were a bit above 200 commits from
me.  Given that 2.18.0 has been released more or less on the eave of
2014, it would appear that I've picked up a solid amount of slack since
doing the mistake of working on Git, work estimated to take a week or
two and actually dragging on for months.

2.19 so far includes a number of architectural fixes that don't make for
an impressive summary, like obliterating basically all special cases
from music function calls in the parser, and now a shortly to be
committed rework of overrides/reverts on subproperties, stuff that never
worked reliably before.  That's very unglamorous stuff that one would
have a hard sell on the user list.  A better sell are spontaneous (and
quite often rather cheap) fixes of reported user problems.  One of the
better sellable features is the use of bare rhythms, like

\new RhythmicStaff \drummode {
  \time 3/4 tambourine
  8 \tuplet 3/2 { 16 16 16 } 8 \tuplet 3/2 { 16 16 16 } 8 8
  8 \tuplet 3/2 { 16 16 16 } 8 \tuplet 3/2 8 { 16 16 16 16 16 16 16 16 16 }
}

At any rate, even in my most productive phases I don't account for much
more than a third of the commits.  One reason is that we have a small
set of determined workers continuously scouring the documentation for
shortcomings and addressing them, and a number of translation workers
closely following on their foot.

That's very important work regarding the uptake of LilyPond, and so it's
a thorn in my own side that the German translation is mostly
languishing.  I actually tried working on it a few times but the problem
is that I end up not just updating it but more like rewriting it from
scratch (funny anecdote: when put through initial tests in the hospital,
just like the first time several years ago the physicians marked my
speech slowed down by the search for proper words, but both I as well as
my partner assured the physicians that this was quite inconspicuous for
me).  But I don't have the time for getting sucked into that as well.

So at any rate: without me LilyPond would most certainly have progressed
to newer versions as well, focusing on different things and making
progress on different things.  While I like to think that creating and
maintaining a solid, reliable and consistent toolset is a fundamental
asset for this kind of user/feature-driven progress, people tend to live
with and hack around even the most annoying limitations and
inconsistencies.

-- 
David Kastrup