reduced development time

[Graham Percival]

2.15.26 is released, containing the fix for issue 1933
lilypond-book on windows.  This marks the end of my active
development work for the next ten weeks: until the end of March, I
am reducing my lilypond time from 10 hours a week to 5 hours a
week.  In practice this means that I can reply to emails and
review patches on countdowns, but likely nothing else.  I can
still build releases from time to time, although those are a pain
because I need to reboot my computer into a different OS from my
normal one.


In terms of my workload, I am quite behind on writing my phd
dissertation and in this spring term I am teaching an additional
10 hours of computer labs each week.  For professional and
personal reasons I need to finish this degree as soon as possible,
and lilypond is the only thing I can cut.

In terms of hobbies... lilypond has ceased to be entertaining or
fulfilling.  When things go well I have a feeling of grim
satisfaction, but more often than not it is a constant stream of
disasters.  Every day brings more emails with problems that I have
no interest in solving but I somehow feel obligated to work on.  I
will re-evaluate my situation at the end of March, but I make no
guarantees about how I will choose to spend my time from then on.


I could end with a plea about getting more people involved, but
those rarely do anything and even besides that, we don't really
have enough mentoring capabilities to afford any new contributors
unless those contributors are highly experienced with open-source
development already (such as Adam and Julien).

Instead, I will end with a plea for more automation.  We
collectively need to stop doing things manually, or if any manual
attention is needed, foist that off to non-technical users.  I'm
talking about walking somebody through editing their .git/config,
checking a patch by manually executing rm mf/out/* && make && make
check, or typing in patch numbers by hand.  I really think that
the best way forward is to stop all such activities, and instead
extend the automatic processes until they can handle those.
Thigns like finishing the CG git instructions, making Patchy more
reliable, fixing build problems and enforcing stricter limits on
errors.  If a patch fails to apply to git or fails to compile
during a Patchy test, an email should be sent to -devel
automatically instead of requiring manual attention.  etc.

Yes, this might mean that some things get delayed by a few weeks
while the automated process is extended to cover that type of
patch, but it can save so much time in the long run -- and it
makes the "routine maintenance" much less unpleasant.  I'm
convinced that a few weeks of serious work on automation, instead
of new features or even bug-fixes to lilypond, would quickly see
great benefits.

Anybody who wants push access to the git-cl repo or the
lilypond-extra repo will get it.

Good luck,
- Graham