Re: Quit [now definitely O/T]

[Carl Sorensen]

Chris, 

Thanks for your contributions.  I'm sorry for whatever part I've played
in discouraging you.


On 11/12/09 11:04 AM, "Chris Snyder" <address@hidden> wrote:

> 
> Over the past year, I've submitted patches on occasion for possible
> inclusion in the trunk. On one occasion (accidentals in chords not
> spaced properly), I spent quite a bit of time implementing a solution
> proposed by one core developer, which took quite a bit of time
> (including a steep learning curve, which I'll discuss below), only to
> have another core developer reject it out of hand as being the wrong
> approach. The rejection left a bad taste in my mouth - it was fairly
> terse, and didn't acknowledge the wasted effort I had expended. Not
> surprisingly, I haven't found the motivation to touch that code again.

I assume you're talking about the issue 415 stuff, found here:

<http://thread.gmane.org/gmane.comp.gnu.lilypond.bugs/14926/>

If so, I read it slightly different than you do.

I read it as Joe giving you some guidance, and Han-Wen saying that he didn't
particularly like Joe's idea, but then Joe and Han-Wen went back and forth a
few times, and the final message I heard from Han-Wen was "sounds good to
me." (see the message at 29 Mar 17:17)  In other words, I think that a
proposed solution that met Han-Wen's sensibilities had been arrived at.

Sure, the first comment Han-Wen made was "I am less than enthused" due to
special casing and duplicate code for reminder and normal accidentals, and
dubious prospects.  It wasn't very gently stated, but it did bring up real
issues.  I'm sure it wasn't intended to say "quit trying", but instead to
say "we need to get the code cleaner before we'll accept it".

So please, pick up your code again, and try to get the patch for 415 into
shape so that it can be applied.  Joe will help you, I'm sure.  And Han-Wen
isn't trying to keep you out; he's just trying to keep the code up to
standard.  We really do *like* patches, even if sometimes it doesn't seem
so.


> 
> Over the past couple of days, I've been working on fixing a couple of
> bugs that were caused by an earlier bug fix I submitted (that was
> accepted). Joe Neeman has given me very constructive comments and asked
> for reasonable improvements. At times, however, I've been struck by the
> level of perfection required for patches such as mine, which seem to be
> much higher than the current code. For instance, I was asked to correct
> some indentation - never mind the fact that the code right around my
> patch was indented incorrectly (I thought about fixing the whole file,
> but didn't want to add noise to the patch set).

If we had a working code janitor who was fixing things up, we could just let
spacing go.  But we don't.

If we had a perfect code-formatting tool, we could just run the files
through the tool.  But we don't.

So we ask to have patches be indented properly.  We expect that as we do so,
we'll fix the mistakes that are currently in the code.  And we'd be happy
to have you submit a patch that would fix the indentation in the file that
had bad indentation.

Just this week, I was applying a patch that Patrick Schmidt gave me for
ly/predefined-guitar-fretboards.ly.  This was code that *I* had written.
When I applied Patrick's patch, it gave me a whitespace error.  And then I
found that the whole file was full of whitespace errors.  So I fixed it.
I think it's much better to expect new code to be done well than to accept
poor indentation with the hope that it will be fixed later.

I realize that it seems like jumping through mindless and unnecessary hoops.
I've been there (had patches rejected because of bad indentation) and I
remember the pain it was to completely reindent the file (as part of that
process I learned to use the automatic indentation in vim).  But my code is
easier to read (which is *really* important for Scheme code IMO), so it's
worth the hassle.

> 
> As I mentioned above (and others have mentioned), the learning curve for
> developing is quite steep. I applaud the effort by Graham et al to
> improve the documentation, especially the Contributor's Guide, which has
> been a big help even in its incomplete form. However, a lot of the code
> is difficult to follow - when is stop_translation_timestep called in
> engravers, for instance? It took me a while to understand that it will
> be called even due to rhythms in other voices besides the one the
> engraver is interested in.

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

> 
> A common response to questions about the code is to
> RTFlilypond-devel_archives, which can be helpful. The problem that I've
> found here is that often I'll find outdated discussions that describe
> the code as it worked in 2001 instead of now, and it's difficult to
> determine when the behavior changed.
> 
> I understand the frustration inherent in helping newbies (until you've
> had to explain to an 85-year-old customer how to find the Start menu in
> Windows, you haven't seen anything<g>), and I understand that a big
> problem is the lack of person-hours to improve the developer
> documentation. However, a change in tone could go a long ways toward
> recruiting and maintaining developers - instead of "RTFlilypond-devel,
> n00b!" how about, "Thanks for your willingness to help. Unfortunately,
> we don't have a lot of documentation for that right now. There were some
> discussions on lilypond-devel about it a while back that should give you
> some guidance, though be aware that the behavior changed in the fall of
> 2004, so disregard anything before that. And feel free to come back with
> any further questions."

I'm sorry you've had a bad experience.  Unfortunately, I think that the
stock answer for virtually every question on how the internals work is:

"Thanks for your willingness to help. Unfortunately,
we don't have a lot of documentation for that right now. And I can't think
of a good discussion that took place on lilypond-devel, but you might find
something if you search the archives.  The recommended way to figure out how
LilyPond works is to read the source.  As you do, you may find some more
specific questions to ask. Please feel free to come back with any further
questions."

I hope this hasn't come across as defensive.  I'm sincerely trying to help.

Thanks,

Carl