Re: Outstanding patches

[Boris Shingarov]

Hi Joe,

> Could you send me a list of the unreviewed patches that you have on
> rietveld? I should have time in the next week or so to review them.
>    

This issue is not so much the patches being "unreviewed" but rather 
"sitting stuck missing an ingredient like a test case".  And this is 
partly a practical and partly a philosophical issue for us here: as I am 
trying very hard to explain (in the presentation and many posts on the 
lists), *my* focus is not advancing LilyPond along its main direction 
(there already is an excellent team doing that), but taking it to other, 
orthogonal, dimensions -- such as making it useful to a musicologist 
preparing a major critical edition.  In this work, we have our own 
limitations which make it very difficult to do proper disciplined 
software development.  Right now, when presented with a technical 
requirement, I have to take the shortest path to satisfy the requirement 
*for this book only*.  I have very limited time to care if the solution 
breaks all other books.  Not that I have a low code standard, but many 
times I have to consciously go against my own standards.  This exercise 
going against developer values is deliberate.  It has to do with being 
customer-centric vs software-centric.

If the solution happens to be close enough to being useful for everybody 
else (this is what I earlier called "10% extra work to get the patch 
accepted"), I submit the patch for review.  But sometimes, "the shortest 
way" differs from the "proper" say by 500%; these are the patches I 
classify within the "future work" category.

This is going to change.  Hopefully, with the success of the work on the 
first volume of the book, will be able to launch a project supporting 
proper mainline LilyPond development.

Now, on to the actual list.  Off the top of my head, there are three.

"Page-spacer gets confused", sits wanting a test case:
http://thread.gmane.org/gmane.comp.gnu.lilypond.bugs/17443/focus=18865
This issue has a duplicate, "Vertical spacing: over-estimation of 
markups height", recently reported by Nicolas:
http://thread.gmane.org/gmane.comp.gnu.lilypond.bugs/18831/focus=18857

"Pure-height of stems", sits wanting a test case:
http://thread.gmane.org/gmane.comp.gnu.lilypond.bugs/18449/focus=18450

Homogeneous treatment of markup and markup-list things, discussed back 
in February and again recently:
http://lists.gnu.org/archive/html/lilypond-devel/2010-02/msg00268.html
http://thread.gmane.org/gmane.comp.gnu.lilypond.devel/28717/focus=28813
http://codereview.appspot.com/207105
With this one, the situations is somewhat more complex because I can see 
the reasons for Nicolas' assessment that the patch makes one markup 
command behave differently from all other markup commands.  I am not yet 
sure if this is ok or bad.  The whole idea of the patch is that a markup 
command can return either a stencil or a list of stencils, and the code 
consuming the result, automatically decides on how to deal with what 
came from the command.  If we take this standpoint, then the patch only 
needs those minor formatting fixes that Carl pointed out.  But one could 
also take Nicolas' standpoint.