Re: [Lilypond-auto] Issue 2783 in lilypond: wrong placement of timesignature

[lilypond]

Comment #10 on issue 2783 by address@hidden: wrong placement of timesignature
http://code.google.com/p/lilypond/issues/detail?id=2783

"marginal benefit": If the starting chord requires a temporal extension, or  
if we have a meter change during a temporal extension...

If you consider yourself a second-class citizen as a user submitting  
patches compared to a user submitting bug reports, please be aware that  
_every_ user using 2.16.0 is forced to use the semantics you have  
submitted, so you are actual the sovereign.  Sovereignty comes with  
responsibility.  In this case, it has been my responsibility to permit this  
patch series into 2.16.0.  I had been considering reverting it in 2.16.0  
right after submission, but decided against it in order not to discourage  
further contributions.  So I placed your interests, or rather LilyPond's  
long-term interest of keeping you motivated in working on it, higher than  
those of the entire user base, with the consequence of having the largest  
user-visible regression (so far) we need to deal with in 2.16.1.

Which is what we are currently trying to do.

Now your submissions tend to conflate several different things into a  
single large patch, which makes reviewing them rather hard, and our usage  
of Rietveld, a single-patch bartering place, makes this an even worse  
idea.  I am aware that we are still in the process of getting you  
acquainted with the workflow.  It took quite a bit of work to at least have  
this patch split into separate pieces, and it turns out that this was a  
good idea since we now have the possibility of actually reverting only that  
part of the patch that turned out problematic.

Please note that "a single user reporting" an issue does not mean that only  
a single user _encounters_ an issue, so it does not mean that we take a  
single user as being more important than a developer, but the entire user  
base has a bit of weight.  There are a number of developers who had a patch  
reverted when an immediate fix was not in sight.  Even when it is, it  
sometimes makes for a cleaner slate to revert and refix.  I think I had a  
(trivial) patch once reverted at least three times in a row because I did  
not get it right.  And actually, it turned out that the final problem was  
elsewhere, but triggered by my patch.

Yes, "predictable solution" and "have to override" is a tradeoff.  For (-4  
2 0 2), there is no "staffline closest to center".  Picking one is not  
predictable.  A quite predictable and overridable solution that catches 90%  
of all use cases is preferable to me over an unpredictable one catching 95%  
of use cases because I don't know when I will have to tackle the remaining  
5%, and how.  And I don't know whether my 5% fix will stay valid.  And  
there is no way one can create a sensible convert-ly rule for automatic  
conversion.

"If you are using irregular stafflines, LilyPond will place the time  
signature somewhere where it feels it makes sense.  You have to check after  
the fact whether this is what you intended, and possibly move it relative  
to wherever it ended up being." is not something I want to write in a  
reference manual.

Yes, it might mean that one part of your contribution, one that you had put  
work and thought in, will not remain in LilyPond, and that is  
disappointing.  Perhaps by discussing your plans more on the LilyPond list  
before submission, this might have been avoided.  And perhaps not.   
Sometimes it takes actually following through with an idea to be able to  
judge its consequences.

We are working on LilyPond together, and I don't think anybody is trying to  
make it harder for others just out of spite.