Re: improving our contributing tools and workflow

[David Kastrup]

Jan Nieuwenhuizen <address@hidden> writes:

> Graham Percival writes:
>
>> On Thu, Sep 26, 2013 at 02:05:44PM +0200, Jan Nieuwenhuizen wrote:
>>> - plain email-based patch submission using a benevolent dictator,
>>>   ie, use git the way it was designed and is still used by the
>>>   creators (linux, git).
>>
>> Are you volunteering to be that benevolent dictator?
>
> I'm sorry, not at this time.
>
>> Spend, say, 15 hours a week reviewing and approving patches?  I have
>> no quarrel if you want to do that.
>
> I do not share this assumption that this setup would cost time.  What I
> am suggesting is that this may help David and core developers if he
> would take this up.  I think that the continued success of Linux
> is for a great part a result of this development setup.
>
> The dictator works closely only with one to three core developers
> hardly bothers with the rest.

Well, you have obviously adjusted the numbers to fit LilyPond better
than Linux, but that setup still calls for one to three core developers
to filter every submission.  Now I readily agree that my gut feeling
about a patch definitely increases when I've seen Keith make it go
through the works in a review.

But there is just so much Keith to go around, and then it is not like he
does not work on patches himself.

Another problem with the dictator role is that he has the managerial,
technical and human competence to deal with direct or at least indirect
submissions in _all_ areas of the code.

For me, much of the code base is inherited.  I'm not actually qualified
to give a blessing to code.  Now if you take a look at the Linux
processes, you'll find that Linus at least is _trusted_ to give an
opinion for anything (and of course, since the Linux master is his
personal repository where nobody else may write, he _is_ the ultimate
arbiter).  He delegates a lot, sure, but when this delegation of trust
breaks his expectations, the fallout can easily make a developer go
away.

We don't have a lot of developers to start with.  When Linus worked with
a set of developers as small as the currently active LilyPond core team,
he was much more friendly, forthcoming, open and helpful.

His leadership style developed as a consequence of things going wrong
and right, and adapted as the size of the project grew.

Now look what a personality I'm starting with...

> He does invest some time in getting those core developers to create
> the kind of patches and code that he likes, so that after some time he
> can pull their patches with hardly looking at them at all.  And that
> as a network all the way down.  That ensures a very high level of
> quality, while freeing up the people at the core.

"All the way down" is a small way for LilyPond.  And we don't have that
many people to free "at the core".

>> The whole system is set up to minimize the demands on main
>> developers.  Any solution which shifts the burden away from
>> contributors and onto main developers is IMO bad for LilyPond.
>
> Of course.

One fundamental difference is the kind of developer and/or helper the
respective projects tend to attract.  LilyPond is conceptually not that
much simpler than an operating system kernel, but it's sexy to quite a
different set of people.  And making it usable requires different focus.
Linux does not have anything remotely close to our documentation system,
let alone translations, and it does not have a frontend and extension
language.  Basically, it's backend all around.

Now we actually could use a _team_ of backend hackers which don't work
on improving _what_ the backend does (that's what Gould and friends
prescribe), but how one tells it how to do that, and how it picks the
path from there.

Because we have reached a state of fragile equilibrium where any
additions require lots of care in order not to break conceptually
unrelated stuff.

That leads to half-done solutions like the skyline stuff: we have the
ability to place staves closer now, and as a result, we now need _more_
pages for any given score.  That's because the ability to place things
closer necessitates more padding, and our page breaker only see the
additional padding but not the ability to place staves closer.

-- 
David Kastrup