[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: sustainable development in LilyPond

From: Trevor Daniels
Subject: Re: sustainable development in LilyPond
Date: Wed, 4 Aug 2010 11:06:38 +0100

Graham Percival wrote Wednesday, August 04, 2010 9:41 AM

On Wed, Aug 04, 2010 at 09:10:25AM +0100, Trevor Daniels wrote:

1) There is no architectural overview and no program logic manual to
guide new developers through the early stages.
This has the advantage that

No; there's no advantage to this.  It's simply due to an imbalance
of high skill, available time/interest, and an overwhelming number
of other concerns.

I'm quite aware of the problems that this causes for new
developers, but as long as we have over 10 patches waiting for
review for the past few months, the current bottleneck is *not* in
the initial "getting started" stages.  The current bottleneck is
reviewing patches.

That's true; but I didn't say this was a current bottleneck,
I said it was a danger to sustainability, the topic we were

The CG section on programming has been improving slowly but
surely, as have the Frogs.  I wish that we had more Frogs
submitting doc patches to the CG explaining the stuff they've
learned instead of leaving that task to the already over-burdened
Carl, but I didn't think it was worth raising this point directly.

I think it is worth pushing.  Most of LM 3 was written as I
learned how to use the IR.  It doesn't matter if a doc patch
is incorrect - it would almost certainly illicit a rapid
response from a core developer and we would all learn.

2) There is no overall design plan to guide future development.
New features are added in an ad hoc fashion at the whim of individual
developers.  The danger is that the overall structure will lose
coherence, properties will increasingly behave in inconsistent ways, and the complexity of the user interface and the barriers to new developers
will increase.
At present we rely on Neil and other core developers to
maintain the integrity of the design by reviewing patches,
but that is not guided development.

This part and parcel with the general way that volunteer
open-source projects work, though.

I know.  It is probably the greatest defect of OSP.

Projects with large commercial
backing (like mozilla and can give a roadmap with
the knowledge that they have 20/50/100 developers to assign as
they wish.

True and of course we can't do this.  But we could set out
some desirable directions and goals.  Consistently thought-out
ones, rather than individual feature requests.  If such a
roadmap existed it might prompt contributors, frogs even, to
work on those items.

We have an opportunity within GLISS and GOP to tackle these
dangers, although their terms of reference would need to be
widened to embrace them.  GLISS would need also to consider
future needs and how they would be accommodated in the
input syntax, and GOP would have to break down the barriers which new
developers currently have to overcome themselves.

This is possible, but I don't think it's realistic.  In
particular, it would need:
1. a large amount of developer time being placed under the control
of a benevolent dictator (or council of dictators), and

Yes.  All the most successful OSP have this.

2. the "mundane" development tasks to be sustainable, and to have
enough effort to cover those tasks without needing to distract any
minions working on #1.

I'd say that we're at least a year away from having sustainable
mundane tasks... the Bug Squad will probably be sustainable in 2-4
months, but GDP utterly failed at creating a sustainable doc team,

Don't run this down.  The docs were immeasurably improved by GDP.
This was beneficial dictatorship in action.

It was and still is unrealistic to expect people to work several
hours a day on LP for more than a year or so (with one or two
dedicated exceptions).  So the goal should be to accommodate a
flow of people coming in, working a while, and then leaving.
So we have to make it as easy as possible for newcomers to
contribute easily and quickly, to both docs and development.
The concept of permanent teams is fine, but not teams with
permanent members - there will always be a flow.

However, IMO we shouldn't be fussing too much about these
long-term issues until 2.14 is out.  We need a stable foundation.
(it's a bit unfortunate that the talk was when it was)

OK, agreed.  I've made my comments while they were in my
mind.  I'll back off now.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]