[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Quit [now definitely O/T]
Re: Quit [now definitely O/T]
Thu, 12 Nov 2009 22:56:34 +0000
On Thu, Nov 12, 2009 at 05:32:26PM -0500, Chris Snyder wrote:
> I think my experience does illustrate the care necessary in shepherding
> new developers. I think the LilyPond developer community would do well
> to treat newbies with kid gloves - contributing to a project for the
> first time can be intimidating. The Frogs program is a good step, but
> it's not very well publicized.
I think your "mistake" -- which was quite a natural response --
was to send the patch to lilypond-devel. One of the ideas behind
the Frogs is that Carl could gently suggest some improvements
privately; then you could send it to the frog mailist for more
general viewing; and then (and only then!) you could send it to
One problem with this model is that Carl (and other people on the
frog list) don't know a lot about the lilypond internals, so your
patch might make it all the way to -devel before getting rejected
due to major architectural grounds. I have no answer to that,
other than "each time this happens, Carl + the frogs will learn
more about the general architecture, and can then spot such
I agree that the Frogs should be better publicized... but that
just brings me back to the new website.
>> If we had a perfect code-formatting tool, we could just run the files
>> through the tool. But we don't.
> I vaguely remember some discussion on this at one point, but I can't
> find anything in the mailing list archives. I'd like to do some
> investigating as to what tools are available - it would save a lot of
There's an issue on the tracker about this; I think it has a link
or two. (I hope it does, at least)
It would be great if you *could* investigate this. Spending days
fluffing around with indentation is a totally stupid waste of
time. Quite apart from the literal waste of time (it's a task a
computer can do!), as you know, it's highly demoralizing. To
everybody involved; experienced developers hate rejecting patches
due to whitespace issues.
This is literally one of the biggest problems for new/learning
developers. I think the website + Frog publicity is more
important, but getting this automated is probably #3.
>> I didn't even know that. I hope we can get this documented. Would you be
>> willing to take a stab at how events are passed to engravers (or how various
>> routines inside an engraver are called from outside the engraver)?
> Perhaps this could be part of a developer tutorial that details creating
> a new engraver from scratch? I'm envisioning a LM-equivalent for the CG
> with the same relationship that the LM has to the NR (the full names of
> which must not be named).
If it's something that a user might do, put it in Extending. If
not, put it in the CG.
If you won't want to merge it with CG 8 (or whichever one is about
programming), we could add a chapter just for programmming. I
mean, programming knowledge, rather than programming