lilypond-devel
[Top][All Lists]
Advanced

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

Re: state of the release: the Good, the Bad, and the Ugly


From: Graham Percival
Subject: Re: state of the release: the Good, the Bad, and the Ugly
Date: Tue, 1 Jun 2010 22:17:03 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Tue, Jun 01, 2010 at 09:26:49AM +0200, David Kastrup wrote:
> Carl Sorensen <address@hidden> writes:
> 
> > I think that there is truth in both of those issues.  For Frogs, I
> > have the responsibility of committing patches.  But for David's patch,
> > it's outside my comfort zone.  Han-Wen and Nicolas reviewed the patch,
> > and thought it looked fine.  I dropped the ball in committing it.
> 
> Why would it be your responsibility?  And if it were: where is the point
> in making someone responsible for committing patches he is not
> comfortable with?

It's his responsibility because he's in charge of the Frogs
project.  Or rather: it's his responsibility because I thought we
needed somebody to do this job, and I managed to convince him to
do it.

As many people have noted, contributing code patches to lilypond
is a confusing and complex task.  An email sent to the -devel list
may or may not receieve any comments; even if it does, there's no
guarantee that the comments will be understood by the contributor
(i.e. if somebody makes a cryptic comment about the internals);
weeks can pass without any feedback to the contributor.

The idea behind the Frogs is that new contributors can be
"apprentices" to an established developer, who will help them in
the process of getting patches accepted.  Initial review should
happen on the frogs list (for things like indentation, variable
names, and mundane code style issues); the patch would go to the
-devel list once the Frogs thought it was fine.  (we hope that the
new contributors would help each other, particularly with things
like code style, so that experienced developers can spend more
time on their own new features, bug fixes, and later-stage
reviewing of patches).


> Complete lack of consideration for Midi: there is no way in the world
> that a user, or programmer can design and implement some engraving
> facility and also implement some Midi results: all manuals are
> effectively silent about Midi:

There is no information about programming midi stuff, but the
Notation reference has an entire section about midi.  I think it's
in chapter 3, but it might be 4.


Cheers,
- Graham



reply via email to

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