DevF response to [GOP2-0] Why are we losing developers?

[Colin Hall]

Hi,

Let me first stress that my main reason not to have contributed to the
Lilypond development for the last years has been the lack of time,
both due to family reasons and an increased work load. So, for me the
amount of contributions from my side (i.e. zero for serveral years)
would have been the same no matter what would have happened to the
procedures for contributing with patches. I do use LilyPond
occasionally and briefly browse the mailing list digests, to see
what's going on, but that's about it.

My contributions to the LilyPond development happened in the early
years where we had a much more anarchistic development process, where
Han-Wen and Jan and to some extent myself and a few other trusted
people just uploaded patches directly into the single development
branch. Since copies of all patches were sent on the mailing list, we
of course did some reviewing of each others patches but it was very
informal compared to today. It worked somehow, primarily since we had
only two main developers and they had a good understanding of the full
implementation.  However, as Han-Wen has pointed out several times on
the mailing lists, there were good reasons to abandon this model of
development since it happened a number of times that serious bugs were
introduced that could have been avoided with better peer
reviewing. Also, at least before git, the only way to branch off a
development branch when doing major changes, was to manually make a
local copy, work on it for a while and try to merge with the main
branch, which in the end resulted in a huge patch that nobody really
could overview. Therefore, also major reorganization of the code was
often done in the main branch, leaving it in an unusable state for a
number of days or even weeks.

It's been interesting to see how the LilyPond development survived and
changed when original main hackers stepped down and the process was
taken over by a larger group of people, whereof in principle none had
a complete overview of the full implementation. Graham deserves a big
thank here, since he managed to steer the development in a sustainable
direction during this process, gradually moving into the current
process with more organized patch handling with reviewing and approval
procedures. Clearly the amount of email exchanges per implemented line
of code has increased a lot and I'm sometimes buffled that so many
have the time and patient to engage in all the long email discussions,
but often the end result is a good improvement to the program, that
not only solves a single bug report of feature request but also
provides a good solution for future development or increased
reliability. I myself have changed to digest mode for all the mailing
lists in order not to drown in emails and to avoid that the Lilypond
emails distract me too much from doing what I do for a living. In the
old days (I didn't say "good old days") it wasn't uncommon that a bug
report/feature request was fixed and even released within a couple of
hours, but at least some of these fixes caused other problems later.

Back to my own lack of contributions. A number of years back, I failed
to renew my ssh key after a computer upgrade and since I didn't manage
to fix it in a few minutes time and it didn't feel urgent I dropped it
and have never pushed anything to git since then. This was about the
same time when the Rietveld code review system was started to be used,
which introduced another small threshold for me. If it hadn't been for
these events, I would probably have contributed a few more short quick
patches, to the implementation and/or documentation, but as I stated
initially, I don't think I would have been able to contribute much in
recent years even if I had spent the time to read the new
instructions.

Even though i used git for some time, I never felt fully comfortable
with it, since I didn't learn the system well enough to really
understand what was going on. Of course I was able to use cook-book
instructions and I know that there are excellent such available in the
contributors guide, but I'm the kind of person who wants to understand
what's going on. Please remember that it's several years back that I
looked at git and that there probably is much better documentation
available now than at that time (not to mention the numerous email
discussions on the LilyPond lists).

What would bring me back to contributing to LilyPond development?
Well, I'm in a situation where I often reject a small project that I
foresee would take me more than 5-15 minutes, since I really should do
other things instead. In the old days, I always had a git clone of the
lilypond source tree and all the development tools installed and the
instructions to submit a patch fitted in 6 lines, see the bottom of
http://lilypond.org/web/devel/participating/. Now we have a
contributors guide with lots of details and you have developed
excellent support tools to simplify things. Still, just reading the
necessary parts of the contributors guide would consume more than the
5-15 minutes, so I'm below the threshold and don't see how I would get
above it. I know it's not a fair comparison, since I had probably
spent many hours accumulated over the years, just to maintain the
build environment. I also know that if I submit a patch in an email,
some kind soul probably will take care of it.

Writing this email probably took me as much time as it would take me
to produce a small patch following the new procedures, so I don't have
any good excuse.

DevF

-- 

Colin Hall