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

[David Kastrup]

Graham Percival <address@hidden> writes:

> 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.

If the job description includes committing stuff on your own
responsibility that you are not comfortable with, like stuff changing
the parser substantially (or whatever else), then the respective
definitions do not seem to fit the task space well.

So I think that either the definition of a frog (namely if I fit it) or
the responsibilities of the frog master (if it means being responsible
for the committing of any patches originating from a frog) need to be
thought over.  But it does not seem that the current responsibility
defaults lead to results many people are happy with.

> 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).

Well, I did not post my patches on the frogs list.  I never even looked
at the frogs list.  And the frogs list is not carried by the gmane.org
server either, so looking at it is not as easy as looking at the
developer list.

I am not sure that a separate list for cushioning beginners from some of
the more ugly development aspects is a workable idea, but then I would
have no clue about that since I am a more ugly development aspect rather
than a beginner.

However, I am rather certain that adding another additional layer before
getting a result would not yield favorable results with either me or the
unfortunate people responsible for catering for me.

I would hate to see such humane resources wasted on me, since the
results, in my particular case, would tend to be opposite to the goal.

>> 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.

I was talking about programming midi stuff.  That there is enough
material in the notation manual to get any output at all, and also to
reassign midi instruments, I'll readily grant.  But that's the minimum
required to actually get midi at all.

It is, for example, not possible to create your own dynamics commands
with an audible result: the documentation on creating dynamics,
including snippets, is silent on that if I am not mistaken.

-- 
David Kastrup