Re: critical issues

[David Kastrup]

"m...@mikesolomon.org"  writes:

> There are two critical issues that we're going to have to start
> seriously thinking about now if 2.18 is going to happen anytime soon:
>
> https://code.google.com/p/lilypond/issues/detail?id=2733
>
> I'm not comfortable marking this critical: not because it is not
> critical for Laura, nor because it may not be our fault, but because
> there is not enough information to know where the problem comes from.
> I have no problem on my homebrewed installation of LilyPond running
> LilyPond book.  I think that it is important to work with a user who
> is having a problem like this, especially if the user is active in
> soliciting developer help, but let's only mark it critical if it is
> somehow a generalized problem (i.e. for all users running a given OS).
> What do you think?

I'll take some look again on Ubuntu, but if I can't reproduce the
problem, it will be hard to guess.  I'll try getting in contact with
Laura then.

> https://code.google.com/p/lilypond/issues/detail?id=2656
>
> This is really bad.  I agree that it is critical.  I unfortunately
> have no way to test this, but do people have an ETA for fixing this?
> If not, it will hold 2.18 up for a long time, in which it may be worth
> pushing the translate_axis patch that I've been holding in the works.

It was critical for 2.16 already.  Without any path forward, 2.18 will
be released with exactly the same problem.  There is no point to delay a
release if we don't know how to work on a problem, and we don't have
people both running Windows as well as knowledgeable enough to debug
that problem.

We are doing all we can for Windows users, but here I don't see how we
will be able to do anything without possibly recruiting new blood.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Janek Warchoł]

On Wed, Mar 27, 2013 at 6:54 AM, Werner LEMBERG  wrote:
>
>> https://code.google.com/p/lilypond/issues/detail?id=2656
>>
>> This is really bad.  I agree that it is critical.  I unfortunately
>> have no way to test this, but do people have an ETA for fixing this?
>> If not, it will hold 2.18 up for a long time, in which it may be
>> worth pushing the translate_axis patch that I've been holding in the
>> works.
>
> As can be seen in comment #26, Behdad is willing to help, but a
> LilyPond developer (or power user) using a Windows box must step
> forward, using a current version of Pango (and probably Harfbuzz) to
> test the issue.  The results should then be added to GUB.

I can do some testing during Easter, if i'll get some assistance (too
busy to figure things out on my own :( ).
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[m...@mikesolomon.org]

On 27 mars 2013, at 07:54, Werner LEMBERG  wrote:

> 
>> https://code.google.com/p/lilypond/issues/detail?id=2656
>> 
>> This is really bad.  I agree that it is critical.  I unfortunately
>> have no way to test this, but do people have an ETA for fixing this?
>> If not, it will hold 2.18 up for a long time, in which it may be
>> worth pushing the translate_axis patch that I've been holding in the
>> works.
> 
> As can be seen in comment #26, Behdad is willing to help, but a
> LilyPond developer (or power user) using a Windows box must step
> forward, using a current version of Pango (and probably Harfbuzz) to
> test the issue.  The results should then be added to GUB.
> 

Someone who "knows what they're doing" (tm) needs to head up the effort and 
send an e-mail to the LilyPond user list recruiting 2-3 power users.  A 1-2 
hour Skype session should be all that is needed for the data gathering.

I'm in wedding mode for the next 3-4 weeks, so that's a no go for me :-(

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Werner LEMBERG]

> https://code.google.com/p/lilypond/issues/detail?id=2656
> 
> This is really bad.  I agree that it is critical.  I unfortunately
> have no way to test this, but do people have an ETA for fixing this?
> If not, it will hold 2.18 up for a long time, in which it may be
> worth pushing the translate_axis patch that I've been holding in the
> works.

As can be seen in comment #26, Behdad is willing to help, but a
LilyPond developer (or power user) using a Windows box must step
forward, using a current version of Pango (and probably Harfbuzz) to
test the issue.  The results should then be added to GUB.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Łukasz Czerwiński]

Thanks for all answers.


On 8 January 2012 23:47, Janek Warchoł  wrote:

> W dniu 8 stycznia 2012 10:11 użytkownik James  napisał:
> > Start by looking here:
> >
> http://code.google.com/p/lilypond/issues/list?can=2&q=&sort=priority&colspec=ID&x=type&y=priority&mode=grid&cells=tiles
>
> Umm, guys, there are 629 open issues in the tracker, and we don't have
>
I can see now 632 issues to be precise and definitely it's not what I
wanted to see...

"priority" field to sort them in any way.  I'm sure that Luke asked
> for some concrete suggestions, and i think a good answer might be
>
> http://code.google.com/p/lilypond/issues/list?can=2&q=opened-after%3A2011%2F7%2F1+Type%3DMaintainability%2CScripts%2CBuild+status%3AAccepted+&colspec=ID+Type+Status+Stars+Owner+Patch+Needs+Summary&x=type&cells=tiles
> (recent build and maintainability issues - important for improving
> development workflow)
>

As I guess, the most critical bugs are those flagged as: Critical, so this
list
contains
the most urgent ones, but probably those with regression are tough ones.

According to our motto the aim of LilyPond is "music engraving to
> everyone" - i'd say it's a very good goal.  It would mean that a
> person with average computer skills (like navigating a web browser and
> using word processor) should be able to create very good engravings of
> not-so-complicated music (e.g. Mozart's "Ave Verum").  I think we're
> quite far from this goal; conductor of our choir didn't manage to
> switch to LilyPond.
>

That's what I meant - apart from engraving, being friendly for a user
(non-programmer / non-latex one) is a big plus and attracts people. I've
attended Human Computer Interface classes and since then I try to remember
constantly about the user friendliness in computer programs.


> > Sibelius and Finale cost hundreds of pounds, LilyPond is free, there
> > is no 'competition'. The output of LP in 99% of cases is much better
> > out of the box than any of those packages can manage -
>

I know that they are expensive, but having an option to buy a "nice GUI
Finale" and "a text editor that after typing many lines of magical
incantations without seeing a single clef or note will eventually produce a
PDF file", an "average computer user" will choose to pay.
The definitions of Finale and Lilypond are not mine (I use Latex and
terminal without problems) - but that how could thoughts of a standard user
look like.

Łukasz
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

Janek Warchoł  writes:

> According to our motto the aim of LilyPond is "music engraving to
> everyone" - i'd say it's a very good goal.  It would mean that a
> person with average computer skills (like navigating a web browser and
> using word processor) should be able to create very good engravings of
> not-so-complicated music (e.g. Mozart's "Ave Verum").  I think we're
> quite far from this goal; conductor of our choir didn't manage to
> switch to LilyPond.

So he did not manage to spell music in LilyPond in a few days.  I am
sure he tried to spell words in English for longer than that before he
gave up.

"Navigating a web browser" are not "average computer skills".  Those are
not computer skills at all.  You need more computer skills to program a
video recorder.

LilyPond is a batch processing system.  It is not an interactive
program.  You need to spell out the tasks.  People for which working
with a command line is an unsurmountable challenge won't work with
LilyPond.

They might get along with some GUI thingy that drives LilyPond as its
backend.

The one thing where LilyPond needs to refocus is getting away more from
the "fiddle around" stuff where you poke a program with a stick for
getting results rather than specifying your task.

But specifying your task in a computer-comprehensible way is not
avoidable.

In the areas of TeX/LaTeX and Emacs programming, I have hit a few
surprise candidates without programming background who put together a
significant body of macros and functions for their own work.  Pretty
much always it turned out that they were specialists in Oriental or
antique languages.

LilyPond is similar.  We can hope to get into a direction where it
requires less fiddling and programming skills, but writing things
directly in a computer language will always require logic, language and
thinking skills.

FORTRAN is a computer language in which good mathematicians can write
efficient numerical algorithms without tremendous programming skills.
As a result, there is a large corpus of numeric programming libraries in
FORTRAN.  It's not all that nice of a programming language, but it does
not add much of a distraction for a mathematician writing down numeric
code and/or using that of others.

If LilyPond manages a state where it does not get in the way of
composers writing down music, that is about the best one can hope to
achieve.  The tools and workflow can be made smoother, but that's it.

Don't _ever_ try to sell LilyPond to somebody who is not warm enough
with a computer to have a preferred editor.  In that case, you should
rather sell something like Frescobaldi.  Something which the user can
actually touch and see.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Janek Warchoł]

W dniu 8 stycznia 2012 02:54 użytkownik Graham Percival
 napisał:
> On Sun, Jan 08, 2012 at 01:52:41AM +0100, Łukasz Czerwiński wrote:
>>  * Let's assume that I would like to help in developing Lilypond, but
>>I don't have my own idea, what part of it I could improve. What
>>would you suggest me to do?
>
> There are tons of open issues on the tracker.

W dniu 8 stycznia 2012 10:11 użytkownik James  napisał:
> Start by looking here:
> http://code.google.com/p/lilypond/issues/list?can=2&q=&sort=priority&colspec=ID&x=type&y=priority&mode=grid&cells=tiles

Umm, guys, there are 629 open issues in the tracker, and we don't have
"priority" field to sort them in any way.  I'm sure that Luke asked
for some concrete suggestions, and i think a good answer might be
http://code.google.com/p/lilypond/issues/list?can=2&q=opened-after%3A2011%2F7%2F1+Type%3DMaintainability%2CScripts%2CBuild+status%3AAccepted+&colspec=ID+Type+Status+Stars+Owner+Patch+Needs+Summary&x=type&cells=tiles
(recent build and maintainability issues - important for improving
development workflow)

>> is there a person (several people?) that could answer
>> such questions [about code style]?
>
> Janek used to be that person, but he gave up.

I didn't have competence to answer questions about how code should be
written.  I was only helping to get the grips with the development
process, that's all.


W dniu 8 stycznia 2012 10:11 użytkownik James  napisał:
>
> 2012/1/8 Łukasz Czerwiński :
>> What's the aim of Lilypond?
>
> err..
> "LilyPond is a music engraving program, devoted to producing the
> highest-quality sheet music possible. It brings the aesthetics of
> traditionally engraved music to computer printouts."

According to our motto the aim of LilyPond is "music engraving to
everyone" - i'd say it's a very good goal.  It would mean that a
person with average computer skills (like navigating a web browser and
using word processor) should be able to create very good engravings of
not-so-complicated music (e.g. Mozart's "Ave Verum").  I think we're
quite far from this goal; conductor of our choir didn't manage to
switch to LilyPond.

> Sibelius and Finale cost hundreds of pounds, LilyPond is free, there
> is no 'competition'. The output of LP in 99% of cases is much better
> out of the box than any of those packages can manage -

I'm sorry but i think that's not true.  Look at the attached pdf -
these are examples of problems in very basic areas of Lily-made
engraving.  Finale delivers better results in these cases, see here:
http://www.sendspace.com/file/7yvb8c
I'd say that there's roughly 50% chance that a score would have more
than one case of a problem like that.


2012/1/8 m...@apollinemike.com :
> I have never not responded sooner or later to a question from a newb 
> (including Janek when he was starting out) about how to do something in 
> LilyPond.

I'd rather say "including Janek every time he tries to do anything",
for what i'm very grateful :)

cheers,
Janek


bad lily.pdf
Description: Adobe PDF document
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[m...@apollinemike.com]

On Jan 8, 2012, at 2:54 AM, Graham Percival wrote:

> On Sun, Jan 08, 2012 at 01:52:41AM +0100, Łukasz Czerwiński wrote:
>> 
>>  Are there some guidelines how to write new code to work in the same
>>  manner as the already written code?
> 
> We have a contributor's guide.  It is not complete, but that's
> where to look.
> 

You can also follow the logic of the code.  For example, let's say that you 
want to fiddle with the X-offset of a Grob.  Read through define-grobs.scm and 
look for all the X-offset callbacks in other grobs.  This'll give you an idea 
of how X-offsets are done in LilyPond.  I think that most current contributors 
learned the code this way.

>> If no, is there a person (several people?) that could answer
>> such questions?
> 

I have never not responded sooner or later to a question from a newb (including 
Janek when he was starting out) about how to do something in LilyPond.

Cheers,
MS


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[James]

Hello,

2012/1/8 Łukasz Czerwiński :

> What's the aim of Lilypond?

err..

"LilyPond is a music engraving program, devoted to producing the
highest-quality sheet music possible. It brings the aesthetics of
traditionally engraved music to computer printouts."

> And why isn't it competing with Finale and
> Sibellius? Aren't all three programs "making PDF files with music"? Of
> course Finale and Sibellius have some other functionalities, but the common
> one is related to PDFs.
> Every computer program and in fact every thing or machine have a "most
> common user". How would you describe a most common user of Lilypond? How
> does he/she use Lilypond, what kind of music (and how complex) does they
> (re-)write? What annoys or disturbs them most in Lilypond?

I keep re-reading this and I just think you want a nice
point-and-click GUI. I don't know what else it is you seem to want
apart from to say LilyPond is 'better' than Sibelius/Finale' in some
vague and probably meaningless way.

Sibelius and Finale cost hundreds of pounds, LilyPond is free, there
is no 'competition'. The output of LP in 99% of cases is much better
out of the box than any of those packages can manage - I know, I have
to sit in my orchestra and read the crud that comes out of the Sib/Fib
stuff.

I can use LilyPond on all the 3 platforms (MacOS, Windows and Linux)
that I use, without any problems at all, move files between the two.
I can use any editor I choose (again important when using 3 different
platforms), the files I use are easily read on *any* version of
LilyPond and apart from the odd complex syntax change of which we have
a simple script to help (convert-ly) I don't have to worry much about
forward incompatibility. There is no typical user, that is a myth as I
am sure it is the same in Sib/Fib.

If you are talking about MIDI output, LilyPond was never intended for
that, it's nice that we have some 'relatively ok' capabilities (no
offence to the MIDI coders - I rarely use MIDI anyway) but all the
Sib/Fib people I know don't use MIDI either, but there are much much
better (and free) tools to produce midi output than Sib/Fib anyway.

if yuo haven't already then I suggest you read

http://lilypond.org/freedom.html

http://lilypond.org/reviews.html

http://lilypond.org/essay.html

Pretty much says it all.

> Let's assume that I would like to help in developing Lilypond, but I don't
> have my own idea, what part of it I could improve. What would you suggest me
> to do?

Start by looking here:

http://code.google.com/p/lilypond/issues/list?can=2&q=&sort=priority&colspec=ID&x=type&y=priority&mode=grid&cells=tiles

Take your pick!

>
>
>> If everybody does it in his own local way, it is more a distraction than
>> anything else.  "How does one do x in LilyPond?" "Depends on whether you
>> are talking about functionality written by Mike, David, Han-Wen, Jan,
>> Graham, Carl or Werner".  That's not what a user wants to hear.
>
> Are there some guidelines how to write new code to work in the same manner
> as the already written code?

Start here:

http://lilypond.org/doc/v2.15/Documentation/contributor/summary-for-experienced-developers

Else:

http://lilypond.org/doc/v2.15/Documentation/contributor/help-us

> If no, is there a person (several people?) that
> could answer such questions?

lilypond-devel@gnu.org


-- 
--

James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Sun, Jan 08, 2012 at 01:52:41AM +0100, Łukasz Czerwiński wrote:
>As for all the emails that were written it the last two days, I believe
>that a sort of coordination is needed in each project.

We have the amount of coordination that we have chosen.

>  * Let's assume that I would like to help in developing Lilypond, but
>I don't have my own idea, what part of it I could improve. What
>would you suggest me to do?

There are tons of open issues on the tracker.

>Are there some guidelines how to write new code to work in the same
>manner as the already written code?

We have a contributor's guide.  It is not complete, but that's
where to look.

> If no, is there a person (several people?) that could answer
> such questions?

Janek used to be that person, but he gave up.  So no, we do not
have any dedicated people that work with new contributors.  A few
developers often give feedback for patches.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Łukasz Czerwiński]

First of all I would like to apologize for misjudging Lilypond project.

As for all the emails that were written it the last two days, I believe
that a sort of coordination is needed in each project. Maybe for some of
them there must be one boss with many programmers and designers, while for
other projects a better solution is to create several small loosely
connected groups, nevertheless each of them having a leader.

As a person who knows only a bit of Lilypond, I would like to get a better
view of Lilypond, so I'd like to ask some questions:

   - What's the aim of Lilypond? And why isn't it competing with Finale and
   Sibellius? Aren't all three programs "making PDF files with music"? Of
   course Finale and Sibellius have some other functionalities, but the common
   one is related to PDFs.
   - Every computer program and in fact every thing or machine have a "most
   common user". How would you describe a most common user of Lilypond? How
   does he/she use Lilypond, what kind of music (and how complex) does they
   (re-)write? What annoys or disturbs them most in Lilypond?
   - Let's assume that I would like to help in developing Lilypond, but I
   don't have my own idea, what part of it I could improve. What would you
   suggest me to do?


If everybody does it in his own local way, it is more a distraction than
> anything else.  "How does one do x in LilyPond?" "Depends on whether you
> are talking about functionality written by Mike, David, Han-Wen, Jan,
> Graham, Carl or Werner".  That's not what a user wants to hear.

Are there some guidelines how to write new code to work in the same manner
as the already written code? If no, is there a person (several people?)
that could answer such questions?

Well, uniform code is nice, modular code is better.  You don't need to
> worry about uniformity if everything actually calls the same code.  And
> if you need to change how it works, being able to do it in one place is
> much less likely to cause problems.  Of course, that needs to touch
> foreign code in a lot of places instead of just leading by example.  And
> that's where actual leadership is helpful since it can _make_ people
> change their _own_ code, and they usually are much better qualified to
> see problems in connection with those changes than a self-appointed
> global janitor can hope to be.
>

I totally agree.


> > I think a good policy is that, when working on that which one wants to
> > work on, one should always strive to do it in a way that leads to
> > better maintainability and extensibility.
>
> If those efforts are not coordinated, there is no end user benefit.
>

"Coordinated" does NOT mean slavery and being a bored, sad programmer ;)
 It just means that no one is "a self-appointed janitor", because there is
always someone, who keeps an eye on some guidelines of a quality of a
Lilypond code.

Hoping to read soon your answers to my questions,
Łukasz Czerwiński
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Janek Warchoł]

David,

2012/1/7 David Kastrup :
> I really don't quite get the point of complaining that I provide
> alternative ways of accessing functionality.  Nobody forces you to make
> use of them.

2012/1/7 David Kastrup :
> In the light of the focus of the work I have been doing for several
> months, I have a hard time not finding your remarks offensive.

I'm very sorry!  I didn't mean that you're doing anything wrong - my
comments were intended to be about lily infrastructure in general.  I
value your work and i think it's very good for LilyPond.  If my words
were offensive to you, i call them off!

my apologies
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

Janek Warchoł  writes:

> What i want to say is, i'm afraid you might have forgotten how it
> feels to be a non-programmer.  It's not a joke that for average person
> that wants to produce some notation, it's hard enough to use text
> input.

In the light of the focus of the work I have been doing for several
months, I have a hard time not finding your remarks offensive.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

Janek Warchoł  writes:

> 2012/1/5 David Kastrup :
>>
>> Janek Warchoł  writes:
>>
>>> 2012/1/4 David Kastrup :
 \layout {
   \layout-from { \compressFullBarRests
     \override Score.SpacingSpanner #'common-shortest-duration =
     #(ly:make-moment 6 10)
   }
   etc...
 }
>>>
>>> ok...  However - i'm very sorry to say this :/ - it would be better if
>>> i wouldn't have to type \layout-from at all.
>>
>> \layout is not the place to accept arbitrary music.
>
> i understand.  I think my answer is "maybe \layout could work
> differently than now"? [1]

Do not think that I came to abolish the documentation or the
programmers; I did not come to abolish but to fulfill.

As you so aptly remarked:
> [1] I think that a more detailed discussion should be a part of GLISS.

Well, I am currently more or less working on a first coming -- first
serving base.  My priority is on making work with the current principles
and design nicer.  If you don't like layout specifications and context
definitions, you just write things like \compressFullBarRests into every
voice and things will work out fine.  In fact, many examples I see start
with something like

global = { \time 4/4 \compressFullBars and whatever else }

...

\new Voice { \global ... }

It just tends to get mucky with implicit voices and grace notes, but the
ways in which it gets mucky are reasonably well-understood.

I really don't quite get the point of complaining that I provide
alternative ways of accessing functionality.  Nobody forces you to make
use of them.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Janek Warchoł]

2012/1/5 David Kastrup :
>
> Janek Warchoł  writes:
>
>> 2012/1/4 David Kastrup :
>>> \layout {
>>>   \layout-from { \compressFullBarRests
>>>     \override Score.SpacingSpanner #'common-shortest-duration =
>>>     #(ly:make-moment 6 10)
>>>   }
>>>   etc...
>>> }
>>
>> ok...  However - i'm very sorry to say this :/ - it would be better if
>> i wouldn't have to type \layout-from at all.
>
> \layout is not the place to accept arbitrary music.

i understand.  I think my answer is "maybe \layout could work
differently than now"? [1]

>> I know that it's not much typing, and that \layout-from is an
>> improvement, but from the end-user perspective it's in fact PITA: when
>> use \layout, when \layout-from?
>
> \layout-from takes music and extracts context definitions.

Say this to a LilyPond newbie.  He'll understand 2 words: "music", "and".

>> :( Again, i'm very sorry beacause from the programmer's perspective
>> it's nothing, but for simple users understanding what \layout does is
>> hard enough;
>
> \layout definitions don't have a syntax compatible with music.

That's exactly what worries me as an end-user who doesn't like to
think when he doesn't absolutely have to.  It's similar to
set-override-tweak problem: for you it's obvious that these are 3
different things, and when to use what.  For me it seems like
unnecessary multiplication of commands that seem to work similar (i.e.
they set some property/parameter/whatever).

> If \layout accepted music and mostly ignored it, simple users would not
> understand what it does, and advanced users would not either.
>
>> And i want to enter notes, not some \overridden << \layoutish
>> ##Scheme## >> :( :( :(
>
> Nobody keeps you from entering \compressFullBarRests and stuff right in
> your music.  That's their default place of writing them.
>
> As a programmer, I prefer putting the declarations where they make sense
> and apply document-wide.  Nobody forces you to do it in that manner if
> you prefer jamming everything explicitly into the music which, after
> all, is the designed user interface for it.

David, you are of course 100% right and i don't want to deny you!
Surely it doesn't make any sense to put declarations intended for
document-wide settings inside actual music declarations.

What i want to say is, i'm afraid you might have forgotten how it
feels to be a non-programmer.  It's not a joke that for average person
that wants to produce some notation, it's hard enough to use text
input.  Let me rephrase that: take a random person who searches for
music notation program and stumbles over out site.  *Learning how to
create* this input

\relative c, {
  \clef "bass"
  \time 3/4
  \tempo "Andante" 4 = 120
  c2 e8 c'
  g'2.
  f4 e d
  c4 c, r
}

is a big enough challenge for such a person.  I guess 50% fails, not
because they're idiots, but because it really is hard if you haven't
done it before (and very few ever wrote code).  I don't like it, but
that's the world we live in.

cheers,
Janek

[1] I think that a more detailed discussion should be a part of GLISS.

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

"m...@apollinemike.com"  writes:

> On Jan 5, 2012, at 9:14 AM, David Kastrup wrote:
>
>> "m...@apollinemike.com"  writes:
>> 
>>> On Jan 5, 2012, at 1:20 AM, Janek Warchoł wrote:
>>> 
 Correct me if i'm wrong, but my impression is that
 there is no particular direction in which we are going.
>>> 
>>> I'm sure that other people have their pet projects as well.  The
>>> ensemble of these projects is the "direction" of LilyPond, and I don't
>>> see why it would need more of a direction that that.
>> 
>> Because
>> a) LilyPond becomes unmaintainable if everybody implementing his own pet
>> project implements his own pet infrastructure and pet APIs for it.
>> b) LilyPond becomes unusable if everybody implementing his own pet
>> project does not bother paving the path for slightly similar pet
>> projects.
>
> I agree with this - I should have added that those who are
> contributing to LilyPond should do so in a way that favors
> extensibility.

If everybody does it in his own local way, it is more a distraction than
anything else.  "How does one do x in LilyPond?" "Depends on whether you
are talking about functionality written by Mike, David, Han-Wen, Jan,
Graham, Carl or Werner".  That's not what a user wants to hear.

> I agree with the "something like" part of your statement.

If I have something like a fire-breathing dragon with a hunger for human
flesh in my backyard, that is scary enough as a starting point for me.
Even if I got the details wrong.

>> As opposed to an artwork, _any_ corner of LilyPond, no matter how
>> small, can _ruin_ the rest.  You tend to think of bugs and bad code
>> of blemishes at most, when they are actually more like fungi that
>> will eat through the whole canvas and cause it to fall apart.
>
> This is not how I think of bugs.  If I thought of bugs like this, I
> wouldn't have taken the time to squash so many bugs in LilyPond over
> the past several months.

Well, "bug" was probably the wrong word to use here.  A bug is an
isolated phenomenon.  Squashing bugs is fine in itself, but if you find
yourself excelling at it, at one point of time you should probably
rather think about how to better lock your alimentaries away.

>> And if the LilyPond code does not make great strides in the direction
>> of becoming boring by doing everything the same way, projects like
>> "use linear programming" will be dead in the water since you can't
>> streamline a garbage heap of disparate code into doing linear
>> programming if you can't even make it do the same things in the same
>> way everywhere before changing that way to a linear programming one.
>
> I agree.  For example:
>
> The new StemTremolo code does less internal moving of the stencil and
> farms this out to callbacks.
> The new Stem code is decoupled from the Flag code and now behaves
> (along with the flag) more like other grobs.
> The Beam scoring code now looks more like the Stem and Tie scoring
> code on the inside.
>
> I did not work on these projects expressly in order to make LilyPond
> more uniform, but in working on them, I tried to move LilyPond to a
> state where its code was uniform.

Well, uniform code is nice, modular code is better.  You don't need to
worry about uniformity if everything actually calls the same code.  And
if you need to change how it works, being able to do it in one place is
much less likely to cause problems.  Of course, that needs to touch
foreign code in a lot of places instead of just leading by example.  And
that's where actual leadership is helpful since it can _make_ people
change their _own_ code, and they usually are much better qualified to
see problems in connection with those changes than a self-appointed
global janitor can hope to be.

> I think a good policy is that, when working on that which one wants to
> work on, one should always strive to do it in a way that leads to
> better maintainability and extensibility.

If those efforts are not coordinated, there is no end user benefit.
He'll still have to learn the individual ways of every part of LilyPond
he is going to work with.  And if the individual ways are all different
but still over-generalized, this becomes more of a distraction than a
benefit.  Generalization is not useful as an example or a proposal in
some corner of the code.  It makes only sense if it is pervasive.  And
if it is left to the individual's discretion, it can only become
pervasive when the individual is working _everywhere_.  LilyPond has
grown beyond the scope of a single-person project, however.

> 
> There are again two methods of removing the causes of faction: the
> one, by destroying the liberty which is essential to its existence;
> the other, by giving to every citizen the same opinions, the same
> passions, and the same interests.

[...]

Diversity is nice in a community.  It isn't in a program.  And it isn't
all too much in a single entity like a person, either.  There is not
much you can sensibly talk about with a fanatic conservative liberal

Re: critical issues

[m...@apollinemike.com]

On Jan 5, 2012, at 9:14 AM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> On Jan 5, 2012, at 1:20 AM, Janek Warchoł wrote:
>> 
>>> Correct me if i'm wrong, but my impression is that
>>> there is no particular direction in which we are going.
>> 
>> I'm sure that other people have their pet projects as well.  The
>> ensemble of these projects is the "direction" of LilyPond, and I don't
>> see why it would need more of a direction that that.
> 
> Because
> a) LilyPond becomes unmaintainable if everybody implementing his own pet
> project implements his own pet infrastructure and pet APIs for it.
> b) LilyPond becomes unusable if everybody implementing his own pet
> project does not bother paving the path for slightly similar pet
> projects.

I agree with this - I should have added that those who are contributing to 
LilyPond should do so in a way that favors extensibility.

> c) Implementors are scarcer than users.
> 
>> In fact, I think that it is because of some sorta unified direction
>> that for-profit programs can often miss out on adding experimental or
>> innovative features.
> 
> Mike, just recently you said something like you had implemented
> something along the line of spanbars, did not actually understand what
> you were doing, it could not actually do the work you intended it to do,
> but you thought there was nothing wrong with leaving it in until
> somebody hit bugs caused by this code.

I agree with the "something like" part of your statement.

> As opposed to an artwork, _any_ corner of LilyPond, no matter how small,
> can _ruin_ the rest.  You tend to think of bugs and bad code of
> blemishes at most, when they are actually more like fungi that will eat
> through the whole canvas and cause it to fall apart.

This is not how I think of bugs.  If I thought of bugs like this, I wouldn't 
have taken the time to squash so many bugs in LilyPond over the past several 
months.

> And if the LilyPond code does not make great strides in the direction of
> becoming boring by doing everything the same way, projects like "use
> linear programming" will be dead in the water since you can't streamline
> a garbage heap of disparate code into doing linear programming if you
> can't even make it do the same things in the same way everywhere before
> changing that way to a linear programming one.
> 

I agree.  For example:

The new StemTremolo code does less internal moving of the stencil and farms 
this out to callbacks.
The new Stem code is decoupled from the Flag code and now behaves (along with 
the flag) more like other grobs.
The Beam scoring code now looks more like the Stem and Tie scoring code on the 
inside.

I did not work on these projects expressly in order to make LilyPond more 
uniform, but in working on them, I tried to move LilyPond to a state where its 
code was uniform.  I think a good policy is that, when working on that which 
one wants to work on, one should always strive to do it in a way that leads to 
better maintainability and extensibility.  Perhaps this is my American bias, 
but I strongly believe that the value of LilyPond is in the innovativeness of 
those who care enough about it to work on it.  LilyPond's becoming more 
maintainable and extensible is a result of the good coding practices of these 
people.  However, I do not think that a grand unified vision of where LilyPond 
should go (short of several guidelines on style and common practice (many of 
which are already in the CG)) is necessary or desirable.


There are again two methods of removing the causes of faction: the one, by 
destroying the liberty which is essential to its existence; the other, by 
giving to every citizen the same opinions, the same passions, and the same 
interests.

It could never be more truly said than of the first remedy, that it was worse 
than the disease. Liberty is to faction what air is to fire, an aliment without 
which it instantly expires. But it could not be less folly to abolish liberty, 
which is essential to political life, because it nourishes faction, than it 
would be to wish the annihilation of air, which is essential to animal life, 
because it imparts to fire its destructive agency.

The second expedient is as impracticable as the first would be unwise. As long 
as the reason of man continues fallible, and he is at liberty to exercise it, 
different opinions will be formed. As long as the connection subsists between 
his reason and his self-love, his opinions and his passions will have a 
reciprocal influence on each other; and the former will be objects to which the 
latter will attach themselves. The diversity in the faculties of men, from 
which the rights of property originate, is not less an insuperable obstacle to 
a uniformity of interests. The protection of these faculties is the first 
object of government. From the protection of different and unequal faculties of 
acquiring property, the possession of different degrees and kinds of property 
immediatel

Re: critical issues

[David Kastrup]

"m...@apollinemike.com"  writes:

> On Jan 5, 2012, at 1:20 AM, Janek Warchoł wrote:
>
>> Correct me if i'm wrong, but my impression is that
>> there is no particular direction in which we are going.
>
> I'm sure that other people have their pet projects as well.  The
> ensemble of these projects is the "direction" of LilyPond, and I don't
> see why it would need more of a direction that that.

Because
a) LilyPond becomes unmaintainable if everybody implementing his own pet
project implements his own pet infrastructure and pet APIs for it.
b) LilyPond becomes unusable if everybody implementing his own pet
project does not bother paving the path for slightly similar pet
projects.
c) Implementors are scarcer than users.

> In fact, I think that it is because of some sorta unified direction
> that for-profit programs can often miss out on adding experimental or
> innovative features.

Mike, just recently you said something like you had implemented
something along the line of spanbars, did not actually understand what
you were doing, it could not actually do the work you intended it to do,
but you thought there was nothing wrong with leaving it in until
somebody hit bugs caused by this code.  You can't debug or understand
this sort of experimental and innovative code, and if you can't
yourself, how can you expect anybody else to do?  This sort of bit rot
which nobody know how to either fix or remove(!) is _lethal_ to a
project.  A few dozen things like that, and nobody can make the product
stable again with reasonable amounts of efforts.  Instead you get
symptom-fixing, taking _huge_ amounts of resources in order to let code
nobody understand not hit fatal situations.  And the code not actually
doing anything useful or reliable is causing man-months of maintenance
work.

As opposed to an artwork, _any_ corner of LilyPond, no matter how small,
can _ruin_ the rest.  You tend to think of bugs and bad code of
blemishes at most, when they are actually more like fungi that will eat
through the whole canvas and cause it to fall apart.

Features and innovations come at a cost.  With good modularization and
infrastructure, their cost and benefits are mostly separable from
others: don't use them, and you don't get troubled by them.

LilyPond is not modular enough for that, and it does not have the
infrastructure.  Those don't fall from the sky, and if they are to fit
their purpose, they will require very little experimentation or
innovation but will be perfectly boring.

And if the LilyPond code does not make great strides in the direction of
becoming boring by doing everything the same way, projects like "use
linear programming" will be dead in the water since you can't streamline
a garbage heap of disparate code into doing linear programming if you
can't even make it do the same things in the same way everywhere before
changing that way to a linear programming one.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[m...@apollinemike.com]

On Jan 5, 2012, at 1:20 AM, Janek Warchoł wrote:

> Correct me if i'm wrong, but my impression is that
> there is no particular direction in which we are going.
> 

I think that it is very difficult to set these goals because different things 
interest different people.  I know that Bertrand and I are chipping away at a 
long standing markup-improvement goal, and I'd like to get smoother 
2D-object-on-the-plane-distance handling, and there's my dream of implementing 
some sort of mixed-integer-quadratic-programming engine in LilyPond (I did some 
tests with quantizing quadratic functions using linear functions, but it 
generates at least 1056 variables for a 500-measure score with 33 
columns per measure and normal line widths quantized at horizontal intervals of 
0.01...).

I'm sure that other people have their pet projects as well.  The ensemble of 
these projects is the "direction" of LilyPond, and I don't see why it would 
need more of a direction that that.  In fact, I think that it is because of 
some sorta unified direction that for-profit programs can often miss out on 
adding experimental or innovative features.

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

Janek Warchoł  writes:

> 2012/1/4 David Kastrup :
 \settingsFrom is actually returning a Scheme expression for \with to
 use.  It makes things rather simpler than more complex, even though it
 constitutes a Scheme expression.
>>>
>>> Um... i would really love to be able to type
>>>  \layout {
>>>  \compressFullBarRests
>>>  \override Score.SpacingSpanner #'common-shortest-duration =
>>> #(ly:make-moment 6 10)
>>>  etc...
>>> }
>>
>> Well, create a layout modification type, let \layout accept Scheme
>> expressions of that type, write a Scheme function \layout-from in
>> analogue to \settingsFrom, and it becomes
>>
>> \layout {
>>   \layout-from { \compressFullBarRests
>> \override Score.SpacingSpanner #'common-shortest-duration =
>> #(ly:make-moment 6 10)
>>   }
>>   etc...
>> }
>
> ok...  However - i'm very sorry to say this :/ - it would be better if
> i wouldn't have to type \layout-from at all.

\layout is not the place to accept arbitrary music.

> I know that it's not much typing, and that \layout-from is an
> improvement, but from the end-user perspective it's in fact PITA: when
> use \layout, when \layout-from?

\layout-from takes music and extracts context definitions.

> :( Again, i'm very sorry beacause from the programmer's perspective
> it's nothing, but for simple users understanding what \layout does is
> hard enough;

\layout definitions don't have a syntax compatible with music.  For
example, \layout-from is a command you could not even write in music.

If \layout accepted music and mostly ignored it, simple users would not
understand what it does, and advanced users would not either.

> And i want to enter notes, not some \overridden << \layoutish
> ##Scheme## >> :( :( :(

Nobody keeps you from entering \compressFullBarRests and stuff right in
your music.  That's their default place of writing them.

As a programmer, I prefer putting the declarations where they make sense
and apply document-wide.  Nobody forces you to do it in that manner if
you prefer jamming everything explicitly into the music which, after
all, is the designed user interface for it.

[\layout-from]

>> It is a bit wonky, but should work for most purposes.
>>
>> At least it works with
>>
>>    \layout-from \accidentalStyle "dodecaphonic"
>>
>> and with the above example.
>
> Wow, thanks!  I hope that i understand what it does and that i'll be
> able to use it :)

It is wonky mostly because we don't have a Scheme interface to context
definitions (so I have to use #{ ... #} and fudge around with module-ref
and module-set! inside).  I am actually surprised it works.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Janek Warchoł]

Adding Luke to recipients again...  (please remember to include him as
he's not signed to our mailing lists),

2012/1/4 David Kastrup :
> Łukasz Czerwiński  writes:
>> Regarding all those fragments of Janek's and David's emails: For some time
>> I have been observing how bug are being fixed in Lilypond and spent some
>> time on conversations with Janek.
>> For me there is almost no team work in Lilypond - only a bunch of geek
>> trying to fix some issues, but without a leader who coordinates all
>> actions.
>
> We have coordinated procedures in place that several people spend
> sizable amounts of time on.  This concerns the way new contributions are
> channeled, and how bugs get registered and releases get made.  Graham is
> doing a lot of work keeping just that going and coordinated.

Indeed and this means: kudos to Graham and the patch/issue team!

>> As far as I remember, some time ago you have tried hard to make some
>> big changes in Lilypond, but finally there was no big revolution...
>
> I am not sure who you are addressing.  Nominally, you are replying to
> Janek, and Janek did spacing changes he not just tried to get through,
> but actually did.

Thank you David for being so kind, but i don't remember any important
spacing issues fixed by me.
(however i'm in the process of gathering data for a truly
revolutionary move; unfortunately estimated time left before the
report will be ready is something like 3 months, because of other
stuff i have to do).

>> Without a leader that will make key design & implementation decisions
>> Lilypond will improve in a slow pace, letting Finale and Sibellius
>> gain more and more users.
>
> Forget Finale and Sibelius.  They are not a problem we need to address
> since they are competing in a different space.

I don't fully agree, but i guess discusssing this is not that important.

>> That means not only fixing critical bugs, but also: anticipating
>> future stability problems, constantly improving end user documentation
>> and the quality of source code (reduce complexity, comment code and so
>> on). By now there is a huge work to be done and Lilypond needs someone
>> who will form guidelines and priorities.
>
> There is no point in working on guidelines and priorities without
> capacities that would be guided and prioritized by them.

I'm amused by your answer, David.  It's very rational and succint; i
know Luke and if something can show him what the problem is it's your
answer.

Luke, i remember that you were doing something for GIMP.  Can you say
how things work there, what the leadership looks like and what could
we learn from them, bearing in mind little time each of us have?

cheers,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Janek Warchoł]

2012/1/4 David Kastrup :
>>> \settingsFrom is actually returning a Scheme expression for \with to
>>> use.  It makes things rather simpler than more complex, even though it
>>> constitutes a Scheme expression.
>>
>> Um... i would really love to be able to type
>>  \layout {
>>  \compressFullBarRests
>>  \override Score.SpacingSpanner #'common-shortest-duration =
>> #(ly:make-moment 6 10)
>>  etc...
>> }
>
> Well, create a layout modification type, let \layout accept Scheme
> expressions of that type, write a Scheme function \layout-from in
> analogue to \settingsFrom, and it becomes
>
> \layout {
>   \layout-from { \compressFullBarRests
> \override Score.SpacingSpanner #'common-shortest-duration =
> #(ly:make-moment 6 10)
>   }
>   etc...
> }

ok...  However - i'm very sorry to say this :/ - it would be better if
i wouldn't have to type \layout-from at all.  I know that it's not
much typing, and that \layout-from is an improvement, but from the
end-user perspective it's in fact PITA: when use \layout, when
\layout-from?  :(  Again, i'm very sorry beacause from the
programmer's perspective it's nothing, but for simple users
understanding what \layout does is hard enough; in fact it would be
nice to get rid of it but that's impossible.
You know, i pretend to be a really dumb user.  And i want to enter
notes, not some \overridden << \layoutish ##Scheme## >> :( :( :(
LilyPond will have a chance of winning large audiences when all input
that is needed to create a full Messiah score will be sth like:

\version x.x.x

\header { ... }
\movement = "Sinfony" {
violin = { (notes) }
...
}
\movement = "Comfort ye" {



\makeScore
\makeParts

:/

>>> Scheme is not hard.  Programming is hard.
>
> And sane program design is, apparently, even harder.  People _don't_
> _ever_ think about improving things.  Instead they hobble along in
> whatever clunky way they see others doing, complaining how clunky it is,
> and likely making it much clunkier by bending it to situations fitting
> even worse than what they have seen.

:(
Have you looked at my patches and if so, does any of them do this?


2012/1/4 David Kastrup :
> "layout-from" =
> #(define-void-function (parser location music)
>   (ly:music?)
>   (_i "To be used in output definitions.  Take the layout instruction
> events from @var{music} and do the equivalent of context modifications
> duplicating their effect.")
>   (define (musicop m mods)
>     (if (music-is-of-type? m 'layout-instruction-event)
>         (ly:add-context-mod
>          mods
>          (case (ly:music-property m 'name)
>            ((PropertySet)
>             (list 'assign
>                   (ly:music-property m 'symbol)
>                   (ly:music-property m 'value)))
>            ((PropertyUnset)
>             (list 'unset
>                   (ly:music-property m 'symbol)))
>            ((OverrideProperty)
>             (list 'push
>                   (ly:music-property m 'symbol)
>                   (ly:music-property m 'grob-property-path)
>                   (ly:music-property m 'grob-value)))
>            ((RevertProperty)
>             (list 'pop
>                   (ly:music-property m 'symbol)
>                   (ly:music-property m 'grob-property-path)
>         (case (ly:music-property m 'name)
>             ((SequentialMusic SimultaneousMusic)
>              (for-each (lambda (x)
>                          (musicop x mods))
>                        (ly:music-property m 'elements)))
>             ((ContextSpeccedMusic)
>              (module-set! (current-module)
>                           (ly:music-property m 'context-type)
>                           #{ \context { $(module-ref (current-module)
>                                                      (ly:music-property m 
> 'context-type))
>                                         $(musicop (ly:music-property m 
> 'element)
>                                                   (ly:make-context-mod))
>                                         } #}
>     mods)
>   (musicop music (ly:make-context-mod)))
>
>
> It is a bit wonky, but should work for most purposes.
>
> At least it works with
>
>    \layout-from \accidentalStyle "dodecaphonic"
>
> and with the above example.

Wow, thanks!  I hope that i understand what it does and that i'll be
able to use it :)

cheers,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Janek Warchoł]

2012/1/4 James :
> hello,
>
> On 3 Jan 2012, at 22:26, Janek Warchoł  wrote:
>> I might have given you a wrong impression, i don't think its really
>> that bad.  There is some teamwork, but no leader indeed.
>
> to use an English expression ... poppycock!
>
> Janek you may have not noticed that the team of Colin,
> Phil and myself along with some of the bug squad managed,
> with the the help of Graham (if you want to call him a 'leader')
> to process a quite impressive number of patches.
>
> Before we managed to get some kind of automation of
> patch testing I personally was fielding about 6 new patches
> a day, producing reg test diffs, make checks and the like.
> Colin was managing all patch countdown and push requests
> while Phil ran around, figuratively speaking, making sure
> things were in order in terms of regressions between dev releases.
> all co ordinated by graham - pretty much.
>
> in the meantime Mike, Keith, Carl and co had plenty of time
> then to fix some long standing bugs, and I am seeing some
> serious work by David to do whatever it is he does with the parser etc.

Indeed, i didn't appreciate enough your work.  I apologize.
Please do not hesitate to correct me when i say something wrong again.

Nevertheless, while administration is done very efficiently as you've
shown, i'm not aware of any mid- or long-term goals set for Lily
except GLISS.  Correct me if i'm wrong, but my impression is that
there is no particular direction in which we are going.

my apologies again,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

David Kastrup  writes:

> Janek Warchoł  writes:
>
>>>  \layout {
>>>    \context {
>>>      \Score
>>>      \with \settingsFrom { \compressFullBarRests }
>>>    }
>>>    \context {
>>>      \Staff
>>>      \with \settingsFrom { \accidentalStyle modern }
>>>    }
>>>  }
>>> }
>>> \end{lilypond}
>>>
>>> \ph is a music function written in Scheme.  Can you understand it?
>>
>> Yes, but i get lost on \parallellMusic :(
>
> It's intended for using.  And yes, it likely could be simpler given
> useful APIs for manipulating Scheme.
>
>>> \settingsFrom is actually returning a Scheme expression for \with to
>>> use.  It makes things rather simpler than more complex, even though it
>>> constitutes a Scheme expression.
>>
>> Um... i would really love to be able to type
>>  \layout {
>>  \compressFullBarRests
>>  \override Score.SpacingSpanner #'common-shortest-duration =
>> #(ly:make-moment 6 10)
>>  etc...
>> }
>
> Well, create a layout modification type, let \layout accept Scheme
> expressions of that type, write a Scheme function \layout-from in
> analogue to \settingsFrom, and it becomes
>
> \layout {
>\layout-from { \compressFullBarRests
>  \override Score.SpacingSpanner #'common-shortest-duration =
>  #(ly:make-moment 6 10)
>}
>etc...
> }
>
> Stuff like that is reasonably straightforward to implement.  It would
> have the advantage that you don't have to know what contexts
> \settingsFrom should be placed in.

"layout-from" =
#(define-void-function (parser location music)
   (ly:music?)
   (_i "To be used in output definitions.  Take the layout instruction
events from @var{music} and do the equivalent of context modifications
duplicating their effect.")
   (define (musicop m mods)
 (if (music-is-of-type? m 'layout-instruction-event)
 (ly:add-context-mod
  mods
  (case (ly:music-property m 'name)
((PropertySet)
 (list 'assign
   (ly:music-property m 'symbol)
   (ly:music-property m 'value)))
((PropertyUnset)
 (list 'unset
   (ly:music-property m 'symbol)))
((OverrideProperty)
 (list 'push
   (ly:music-property m 'symbol)
   (ly:music-property m 'grob-property-path)
   (ly:music-property m 'grob-value)))
((RevertProperty)
 (list 'pop
   (ly:music-property m 'symbol)
   (ly:music-property m 'grob-property-path)
 (case (ly:music-property m 'name)
 ((SequentialMusic SimultaneousMusic)
  (for-each (lambda (x)
  (musicop x mods))
(ly:music-property m 'elements)))
 ((ContextSpeccedMusic)
  (module-set! (current-module)
   (ly:music-property m 'context-type)
   #{ \context { $(module-ref (current-module)
  (ly:music-property m 
'context-type))
 $(musicop (ly:music-property m 
'element)
   (ly:make-context-mod))
 } #}
 mods)
   (musicop music (ly:make-context-mod)))


It is a bit wonky, but should work for most purposes.

At least it works with

\layout-from \accidentalStyle "dodecaphonic"

and with the above example.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

Łukasz Czerwiński  writes:

> On 3 January 2012 21:47, Janek Warchoł  wrote:
>
>>
>> > I am a TeX specialist, system programmer, Emacs specialist, the GNU
>> > maintainer (and a rather pitiful one) for AUCTeX (lytex and itexi
>> > anybody? preview-latex for Lilypond?)
>
> Mmm... Preview for Lilypond? Sounds like a good start for a realtime
> GUI for Lilypond (a better Denemo). I believe this will result in a
> fast increase in number of Lilypond users. What do you think?

It won't.  People who are into Emacs won't be into Finale or Sibelius
anyway.  It will increase the ratio of LilyPond users using Emacs for
editing, and possibly the productivity of users of that combination.

But recruiting new users to both LilyPond and Emacs at the same time is
not going to show impressive results.

It is a reasonable expectation to get preview-latex cooperate with
lilypond-book in LaTeX mode with reasonable effort.  To yield a sizable
boost in productivity for LilyPond development, however, preview-latex
would have to cooperate with Texinfo.

Technologically, this is challenging and exciting.  Unfortunately, for
myself the excitement is somewhat stale since I already implemented
preview-latex once.

> Regarding all those fragments of Janek's and David's emails: For some time
> I have been observing how bug are being fixed in Lilypond and spent some
> time on conversations with Janek.
> For me there is almost no team work in Lilypond - only a bunch of geek
> trying to fix some issues, but without a leader who coordinates all
> actions.

We have coordinated procedures in place that several people spend
sizable amounts of time on.  This concerns the way new contributions are
channeled, and how bugs get registered and releases get made.  Graham is
doing a lot of work keeping just that going and coordinated.

New developments are not coordinated to a significant degree, and part
of the reason is that there are no free resources to coordinate.

> As far as I remember, some time ago you have tried hard to make some
> big changes in Lilypond, but finally there was no big revolution...

I am not sure who you are addressing.  Nominally, you are replying to
Janek, and Janek did spacing changes he not just tried to get through,
but actually did.  If you are trying to address my work: I did a lot of
big changes to LilyPond but you would not notice much of it unless you
read the manual, and even then much of it is underdocumented.  A lot of
it is hidden in making naively written code work and giving more power
more easily accessible to the somewhat above-average user as opposed to
the geniuses required before.

> Without a leader that will make key design & implementation decisions
> Lilypond will improve in a slow pace, letting Finale and Sibellius
> gain more and more users.

Forget Finale and Sibelius.  They are not a problem we need to address
since they are competing in a different space.  Our real problem is
LilyPond.

> Probably some of you will return to the old row - is a goal of a
> Lilypond to substitue Finale or compete with Sibellius. I think there
> is no point in loosing your energy *and time* on that.  Instead we
> should do as much as possible to constantly improve Lilypond.

Preaching to the choir, I see.

> That means not only fixing critical bugs, but also: anticipating
> future stability problems, constantly improving end user documentation
> and the quality of source code (reduce complexity, comment code and so
> on). By now there is a huge work to be done and Lilypond needs someone
> who will form guidelines and priorities.

There is no point in working on guidelines and priorities without
capacities that would be guided and prioritized by them.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Łukasz Czerwiński]

On 3 January 2012 21:47, Janek Warchoł  wrote:

>
> > I am a TeX specialist, system programmer, Emacs specialist, the GNU
> > maintainer (and a rather pitiful one) for AUCTeX (lytex and itexi
> > anybody? preview-latex for Lilypond?)

Mmm... Preview for Lilypond? Sounds like a good start for a realtime GUI
for Lilypond (a better Denemo). I believe this will result in a fast
increase in number of Lilypond users. What do you think?


> I would have no problems spending a few hundred man years focused on
> > Lilypond.  Except that I don't have a few hundred man years.  Nobody
> > has.  The next best option is spending time on multipliers.  Getting
> > LilyPond in a shape where passersby find it intriguing, to a degree
> > where they get hooked and contribute manmonths of work over some time
> > without having planned to do so at the start.
>
> +1
>

and:

> > The only thing that is going to help is more eyes, more people who get

> interested, more people discovering dark corners and doing something

> about them.


and:


> To get there, we need serious programmers and serious musicians

> interested seriously in LilyPond.  To a level where they start asking

> good questions.  And we better be in a position to provide answers,

> since there is no more effective way to spend our time than on getting

> more people to spend their time, and love, and interest.


and:

> That's like + from me!
> In general, i agree that we should think in a more 'release-oriented'
> way ("last stable release was half a year ago, so we should make
> another one, so i'm fixing whatever needs to be fixed to make this
> possible") instead of 'free coding' way ("i care about this issue,
> i'll fix it.  And that one.  Oh, we have 0 criticals, so let's make a
> stable release before an obstruction occurs!").  To do so, we would
> have to work more as a team, less independently.  How can we achieve
> that if GOP7 showed that we don't want to?


and:

> And we better be in a position to provide answers,
> > since there is no more effective way to spend our time than on getting
> > more people to spend their time, and love, and interest.


Regarding all those fragments of Janek's and David's emails: For some time
I have been observing how bug are being fixed in Lilypond and spent some
time on conversations with Janek.
For me there is almost no team work in Lilypond - only a bunch of geek
trying to fix some issues, but without a leader who coordinates all
actions. As far as I remember, some time ago you have tried hard to make
some big changes in Lilypond, but finally there was no big revolution...
Without a leader that will make key design & implementation decisions
Lilypond will improve in a slow pace, letting Finale and Sibellius gain
more and more users. Probably some of you will return to the old row - is a
goal of a Lilypond to substitue Finale or compete with Sibellius. I think
there is no point in loosing your energy *and time* on that.
Instead we should do as much as possible to constantly improve Lilypond.
That means not only fixing critical bugs, but also: anticipating future
stability problems, constantly improving end user documentation and the
quality of source code (reduce complexity, comment code and so on). By now
there is a huge work to be done and Lilypond needs someone who will form
guidelines and priorities.

Łukasz (Luke)
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

Janek Warchoł  writes:

>>  \layout {
>>    \context {
>>      \Score
>>      \with \settingsFrom { \compressFullBarRests }
>>    }
>>    \context {
>>      \Staff
>>      \with \settingsFrom { \accidentalStyle modern }
>>    }
>>  }
>> }
>> \end{lilypond}
>>
>> \ph is a music function written in Scheme.  Can you understand it?
>
> Yes, but i get lost on \parallellMusic :(

It's intended for using.  And yes, it likely could be simpler given
useful APIs for manipulating Scheme.

>> \settingsFrom is actually returning a Scheme expression for \with to
>> use.  It makes things rather simpler than more complex, even though it
>> constitutes a Scheme expression.
>
> Um... i would really love to be able to type
>  \layout {
>  \compressFullBarRests
>  \override Score.SpacingSpanner #'common-shortest-duration =
> #(ly:make-moment 6 10)
>  etc...
> }

Well, create a layout modification type, let \layout accept Scheme
expressions of that type, write a Scheme function \layout-from in
analogue to \settingsFrom, and it becomes

\layout {
   \layout-from { \compressFullBarRests
 \override Score.SpacingSpanner #'common-shortest-duration =
 #(ly:make-moment 6 10)
   }
   etc...
}

Stuff like that is reasonably straightforward to implement.  It would
have the advantage that you don't have to know what contexts
\settingsFrom should be placed in.

Again:

>> Scheme is not hard.  Programming is hard.

And sane program design is, apparently, even harder.  People _don't_
_ever_ think about improving things.  Instead they hobble along in
whatever clunky way they see others doing, complaining how clunky it is,
and likely making it much clunkier by bending it to situations fitting
even worse than what they have seen.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[James]

hello,

On 3 Jan 2012, at 22:26, Janek Warchoł  wrote:

> Hi Luke,
> 
> nice to see you joining the discussion :)
> 
> W dniu 3 stycznia 2012 23:06 użytkownik Łukasz Czerwiński
>  napisał:
>>> That's like + from me!
>>> In general, i agree that we should think in a more 'release-oriented'
>>> way ("last stable release was half a year ago, so we should make
>>> another one, so i'm fixing whatever needs to be fixed to make this
>>> possible") instead of 'free coding' way ("i care about this issue,
>>> i'll fix it.  And that one.  Oh, we have 0 criticals, so let's make a
>>> stable release before an obstruction occurs!").  To do so, we would
>>> have to work more as a team, less independently.  How can we achieve
>>> that if GOP7 showed that we don't want to?
>> 
>> and:
>> 
 And we better be in a position to provide answers,
 since there is no more effective way to spend our time than on getting
 more people to spend their time, and love, and interest.
>> 
>> Regarding all those fragments of Janek's and David's emails: For some time I
>> have been observing how bugs are being fixed in Lilypond and spent some time
>> on conversations with Janek.
>> For me there is almost no team work in Lilypond - only a bunch of geek
>> trying to fix some issues, but without a leader who coordinates all actions.
> 
> I might have given you a wrong impression, i don't think its really
> that bad.  There is some teamwork, but no leader indeed.

to use an English expression ... poppycock!

Janek you may have not noticed that the team of Colin, Phil and myself along 
with some of the bug squad managed, with the the help of Graham (if you want to 
call him a 'leader') to process a quite impressive number of patches. 

Before we managed to get some kind of automation of patch testing I personally 
was fielding about 6 new patches a day, producing reg test diffs, make checks 
and the like. Colin was managing all patch countdown and push requests while 
Phil ran around, figuratively speaking, making sure things were in order in 
terms of regressions between dev releases. all co ordinated by graham - pretty 
much.

in the meantime Mike, Keith, Carl and co had plenty of time then to fix some 
long standing bugs, and I am seeing some serious work by David to do whatever 
it is he does with the parser etc.

All of which we still pretty much managed to keep a relatively stable tree with 
one or two hiccups which considering the amount of pushed changes and the 
fundamental stuff the coders were free to do because of them not having to 
worry about things like ... oh testing their patches don't break the main tree, 
spotting quickly any potential issues or breakages because now they can focus 
on reviews of code than having to administer them, that new features are 
documented and that all emails from users complaining about this and that are 
documented themselves in a tracker completely makes that claim ridiculous and 
rather gets on my wick( to use another expression).

comments like that from Luke are unhelpful, disrespectful to many of us and 
frankly, tedious.


> 
>> As far as I remember, some time ago you have tried hard to make some big
>> changes in Lilypond, but finally there was no big revolution...

Maybe before my time, however instead of complaining how about doing something 
constructive?


> 
> Hmm?  I remember that i mentioned to you the rewrite of vertical
> spacing system, which was implemented quite successfully.
> 
>> Without a leader that will make key design & implementation decisions
>> Lilypond will improve in a slow pace, letting Finale and Sibellius gain more
>> and more users.

So what?

it's not a competition. 


>> Probably some of you will return to the old row - is a goal
>> of a Lilypond to substitue Finale or compete with Sibellius. I think there
>> is no point in loosing your energy and time on that.

Yet you just did. some of us aren't fixated wit the stupid Sibfib comparison or 
even care. 

>> Instead we should do as much as possible to constantly improve Lilypond.
>> That means not only fixing critical bugs, but also: anticipating future
>> stability problems, constantly improving end user documentation and the
>> quality of source code (reduce complexity, comment code and so on). By now
>> there is a huge work to be done and Lilypond needs someone who will form
>> guidelines and priorities.

yeah, blah blah ... some of us already know and some of us are getting on with 
it instead of complaining.



James
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Janek Warchoł]

Hi Luke,

nice to see you joining the discussion :)

W dniu 3 stycznia 2012 23:06 użytkownik Łukasz Czerwiński
 napisał:
>> That's like + from me!
>> In general, i agree that we should think in a more 'release-oriented'
>> way ("last stable release was half a year ago, so we should make
>> another one, so i'm fixing whatever needs to be fixed to make this
>> possible") instead of 'free coding' way ("i care about this issue,
>> i'll fix it.  And that one.  Oh, we have 0 criticals, so let's make a
>> stable release before an obstruction occurs!").  To do so, we would
>> have to work more as a team, less independently.  How can we achieve
>> that if GOP7 showed that we don't want to?
>
> and:
>
>> > And we better be in a position to provide answers,
>> > since there is no more effective way to spend our time than on getting
>> > more people to spend their time, and love, and interest.
>
> Regarding all those fragments of Janek's and David's emails: For some time I
> have been observing how bugs are being fixed in Lilypond and spent some time
> on conversations with Janek.
> For me there is almost no team work in Lilypond - only a bunch of geek
> trying to fix some issues, but without a leader who coordinates all actions.

I might have given you a wrong impression, i don't think its really
that bad.  There is some teamwork, but no leader indeed.

> As far as I remember, some time ago you have tried hard to make some big
> changes in Lilypond, but finally there was no big revolution...

Hmm?  I remember that i mentioned to you the rewrite of vertical
spacing system, which was implemented quite successfully.

> Without a leader that will make key design & implementation decisions
> Lilypond will improve in a slow pace, letting Finale and Sibellius gain more
> and more users. Probably some of you will return to the old row - is a goal
> of a Lilypond to substitue Finale or compete with Sibellius. I think there
> is no point in loosing your energy and time on that.
> Instead we should do as much as possible to constantly improve Lilypond.
> That means not only fixing critical bugs, but also: anticipating future
> stability problems, constantly improving end user documentation and the
> quality of source code (reduce complexity, comment code and so on). By now
> there is a huge work to be done and Lilypond needs someone who will form
> guidelines and priorities.

That's generally true and i'd love to have a leader and lots of
teamwork, but who would be the leader?  It would be a time-consuming
task, none of our current developers has much spare time; it would
also require lots of knowledge, so only few would qualify :(
You might consider reading
http://lilypond.org/doc/v2.15/Documentation/contributor/gop_002dprop-7-_002d-developers-as-resources
It's simply that we discussed this before and didn't manage to do
these (good) things you propose.

cheers,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Janek Warchoł]

2012/1/3 David Kastrup :
> Janek Warchoł  writes:
>
>> 2012/1/3 David Kastrup :
>
>>> LilyPond needs to get into a state where, say, half the
>>> engravers are written and maintained in Scheme.  And by "Scheme" I don't
>>> mean "Scheme at the level Nicolas can barely handle" but "Scheme a
>>> Fortran programmer would not have all too much of a problem
>>> understanding".
>>
>> Umm, impossible?  From my perspective, 'Scheme' and 'easy to
>> understand' are mutually exclusive.  Unless there are more comments
>> than code - literally - but we don't do so.
>
> Well, as an example, take a look at
> http://nicolas.sceaux.free.fr/prelude/prelude.html>

Hmm, excuse me while my brain melts ;)

> Now take a look at
>
> \begin{lilypond}
> ph = #(define-music-function (parser location p1 p2 p3 p4 p5)
>       (ly:pitch? ly:pitch? ly:pitch? ly:pitch? ly:pitch?)
>       #{
>          \repeat unfold 2 { $p1 2 } |
>          \repeat unfold 2 { r16 $p2 8. ~ $p2 4 } |
>          \repeat unfold 2 { r8 $p3 16 $p4 $p5 $p3 $p4 $p5 } |
>       #})
> \parallelMusic #'(low middle high)
> {
>  \ph c'   e'  g' c'' e''
>  R1*7 | \skip 1*7 | R1*7 |
>  \ph a    c'  e' g' c''
>  \voiceTwo | \change Staff = "down" \voiceOne | \oneVoice |
>  \ph d    a   d' fis' c''
>  R1*21 | \skip 1*21 | R1*21 |
>  \ph c,   c   g bes e'
>  c,2~ c, | r16 c8. ~ c4 ~ c2
>  | r8 f16 a c' f' c' a c' a f a f d f d |
>  c,2~ c, | r16 b,8. ~ b,4 ~ b,2
>  | r8 g'16 b' d'' f'' d'' b' d'' b' g' b' d' f' e' d' |
>  c,1\fermata | c1 | 1\fermata \bar "|." |
> }
> \score {
>  \new PianoStaff <<
>    \new Staff = "up" {
>      << \high \\ \middle >>
>    }
>    \new Staff = "down" {
>      \clef bass
>      \low
>    }
>  >>
>
>  \midi {
>    \context {
>      \Score
>      \with \settingsFrom { \tempo 4 = 80 }
>    }
>  }
>
>  \layout {
>    \context {
>      \Score
>      \with \settingsFrom { \compressFullBarRests }
>    }
>    \context {
>      \Staff
>      \with \settingsFrom { \accidentalStyle modern }
>    }
>  }
> }
> \end{lilypond}
>
> \ph is a music function written in Scheme.  Can you understand it?

Yes, but i get lost on \parallellMusic :(

> \settingsFrom is actually returning a Scheme expression for \with to
> use.  It makes things rather simpler than more complex, even though it
> constitutes a Scheme expression.

Um... i would really love to be able to type
 \layout {
 \compressFullBarRests
 \override Score.SpacingSpanner #'common-shortest-duration =
#(ly:make-moment 6 10)
 etc...
}

> Scheme is not hard.  Programming is hard.  And there is still far too
> much repetitive programming required for stuff that could be handled
> using shrinkwrapped tools (\settingsFrom is such a tool) if anybody had
> bothered packaging them.  Far too often if I think "Ok, task x has no
> documented way of dealing with it.  Let's see whether we can find an
> undocumented API".  And then I find about 10 files implementing their
> own ad hoc API that will break in different ways if one has to change
> the data structures at some point of time.

I agree, this should not work like that.

Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

Janek Warchoł  writes:

> 2012/1/3 David Kastrup :

>> LilyPond needs to get into a state where, say, half the
>> engravers are written and maintained in Scheme.  And by "Scheme" I don't
>> mean "Scheme at the level Nicolas can barely handle" but "Scheme a
>> Fortran programmer would not have all too much of a problem
>> understanding".
>
> Umm, impossible?  From my perspective, 'Scheme' and 'easy to
> understand' are mutually exclusive.  Unless there are more comments
> than code - literally - but we don't do so.

Well, as an example, take a look at
http://nicolas.sceaux.free.fr/prelude/prelude.html>

Now take a look at

\begin{lilypond}
ph = #(define-music-function (parser location p1 p2 p3 p4 p5)
   (ly:pitch? ly:pitch? ly:pitch? ly:pitch? ly:pitch?)
   #{
  \repeat unfold 2 { $p1 2 } |
  \repeat unfold 2 { r16 $p2 8. ~ $p2 4 } |
  \repeat unfold 2 { r8 $p3 16 $p4 $p5 $p3 $p4 $p5 } |
   #})  
\parallelMusic #'(low middle high)
{
  \ph c'   e'  g' c'' e''
  R1*7 | \skip 1*7 | R1*7 |
  \ph ac'  e' g' c''
  \voiceTwo | \change Staff = "down" \voiceOne | \oneVoice |
  \ph da   d' fis' c''
  R1*21 | \skip 1*21 | R1*21 |
  \ph c,   c   g bes e'
  c,2~ c, | r16 c8. ~ c4 ~ c2
  | r8 f16 a c' f' c' a c' a f a f d f d |
  c,2~ c, | r16 b,8. ~ b,4 ~ b,2
  | r8 g'16 b' d'' f'' d'' b' d'' b' g' b' d' f' e' d' |
  c,1\fermata | c1 | 1\fermata \bar "|." |
}
\score {
  \new PianoStaff <<
\new Staff = "up" {
  << \high \\ \middle >>
}
\new Staff = "down" {
  \clef bass
  \low
}
  >>
  
  \midi {
\context {
  \Score
  \with \settingsFrom { \tempo 4 = 80 }
}
  }

  \layout {
\context {
  \Score
  \with \settingsFrom { \compressFullBarRests }
}
\context {
  \Staff
  \with \settingsFrom { \accidentalStyle modern }
}
  }
}  
\end{lilypond}

\ph is a music function written in Scheme.  Can you understand it?
\settingsFrom is actually returning a Scheme expression for \with to
use.  It makes things rather simpler than more complex, even though it
constitutes a Scheme expression.

Scheme is not hard.  Programming is hard.  And there is still far too
much repetitive programming required for stuff that could be handled
using shrinkwrapped tools (\settingsFrom is such a tool) if anybody had
bothered packaging them.  Far too often if I think "Ok, task x has no
documented way of dealing with it.  Let's see whether we can find an
undocumented API".  And then I find about 10 files implementing their
own ad hoc API that will break in different ways if one has to change
the data structures at some point of time.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues -- hope you're having fun

[David Kastrup]

Graham Percival  writes:

> On Tue, Jan 03, 2012 at 02:57:24PM +0100, David Kastrup wrote:
>> James  writes:
>> 
>> > My question to David, because I am not getting where the 'ire' is
>> > coming from, why do you care if we release dev after dev release vs
>> > stable?
>
> Yeah, especially since Carl was *already* making good progress on
> the GUB-related critical issues.
>
>> http://xkcd.com/386/>
>
> yep.
>
> Let's cut to the chase: I am an evil semi-overlord.  I jealously
> guard my ssh login to lilypond.org (along with Han-Wen's and
> Jan's), I am fickle, and I like to play with small kittens.  Due
> to my evil fickle nature, I am not going to change the stated
> policy until it has been in place for at least 12 months.  Any
> critical issue will block a stable release.  I am chuckling
> maniacally and delighting in how evil and wrong I am being.
>
> Don't like it?  You have three (effective) options:
> 1. don't add regressions.

The problem is that this actually falls into the categories
1a) don't mention regressions
1b) don't make significant enhancements
1c) don't contribute enhancements

> 2. fix (or help fix) any critical issues.

This is usually implemented as
2a) shrug your shoulders since they don't concern you and wait another
year.

> 3. build your own binary releases.

Usually done as

3a) never mind, I got my own checkout.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues -- hope you're having fun

[James]

Hello,

On 3 January 2012 20:49, Graham Percival  wrote:
> On Tue, Jan 03, 2012 at 02:57:24PM +0100, David Kastrup wrote:
>> James  writes:
>>
>> > My question to David, because I am not getting where the 'ire' is
>> > coming from, why do you care if we release dev after dev release vs
>> > stable?
>
> Yeah, especially since Carl was *already* making good progress on
> the GUB-related critical issues.
>
>> http://xkcd.com/386/>
>
> yep.
>
> Let's cut to the chase: I am an evil semi-overlord.  I jealously
> guard my ssh login to lilypond.org (along with Han-Wen's and
> Jan's), I am fickle, and I like to play with small kittens.  Due
> to my evil fickle nature, I am not going to change the stated
> policy until it has been in place for at least 12 months.  Any
> critical issue will block a stable release.  I am chuckling
> maniacally and delighting in how evil and wrong I am being.
>
> Don't like it?  You have three (effective) options:
> 1. don't add regressions.
> 2. fix (or help fix) any critical issues.
> 3. build your own binary releases.
>
>
>
> Finally: I bet that Hitler had strong opinions on when open-source
> projects should release stable versions.
>
> Hugs and kisses,
> - Graham

http://en.wikipedia.org/wiki/Godwin's_law

!

-- 
--

James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues -- hope you're having fun

[Graham Percival]

On Tue, Jan 03, 2012 at 02:57:24PM +0100, David Kastrup wrote:
> James  writes:
> 
> > My question to David, because I am not getting where the 'ire' is
> > coming from, why do you care if we release dev after dev release vs
> > stable?

Yeah, especially since Carl was *already* making good progress on
the GUB-related critical issues.

> http://xkcd.com/386/>

yep.

Let's cut to the chase: I am an evil semi-overlord.  I jealously
guard my ssh login to lilypond.org (along with Han-Wen's and
Jan's), I am fickle, and I like to play with small kittens.  Due
to my evil fickle nature, I am not going to change the stated
policy until it has been in place for at least 12 months.  Any
critical issue will block a stable release.  I am chuckling
maniacally and delighting in how evil and wrong I am being.

Don't like it?  You have three (effective) options:
1. don't add regressions.
2. fix (or help fix) any critical issues.
3. build your own binary releases.



Finally: I bet that Hitler had strong opinions on when open-source
projects should release stable versions.

Hugs and kisses,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Janek Warchoł]

2012/1/3 David Kastrup :
> Janek Warchoł  writes:
>
>> 2012/1/3 David Kastrup :
>>> The Learning Guide and the Notation Guide need a complete rereading and
>>> reorganization, and it is not like the Extending Guide is in
>>> significantly better shape.
>>
>> I'd like to fix them too, but i don't have time for everything i want
>> :(  Splitting my time doesn't look like a good idea - it's more
>> effective when i put all my foxus on one thing, analyze it deeply and
>> make a complete solution than swap issues.  I have to choose and i
>> choose improving graphical output.
>
> I am a TeX specialist, system programmer, Emacs specialist, the GNU
> maintainer (and a rather pitiful one) for AUCTeX (lytex and itexi
> anybody? preview-latex for Lilypond?), know how to make Emacs read data
> from Midi ports, am pretty good concerning compiler writing, shell
> scripting, general programming, efficient algorithms, am the resident
> quiz person for git and so on and so on.
>
> I would have no problems spending a few hundred man years focused on
> Lilypond.  Except that I don't have a few hundred man years.  Nobody
> has.  The next best option is spending time on multipliers.  Getting
> LilyPond in a shape where passersby find it intriguing, to a degree
> where they get hooked and contribute manmonths of work over some time
> without having planned to do so at the start.

+1

> LilyPond has great infrastructure: it makes by far the most from Texinfo
> from any application I know, with much better HTML than upstream, far
> more thorough and good use of images (only useful in HTML or with Emacs
> as info reader, I am afraid).  I have no clue why or how GUB works, but
> many others don't have something like that.  It has good facilities for
> internationalization.  There are other novel pieces that turn out to be
> more of a maintenance problem than an asset because of a total lack of
> documentation and/or mindshare: yaffut, the organization of the C++
> core, many internals, stepmake, ...  Many corners are lying dormant
> since their respective driving force went away or lost interest or time.
>
> I don't manage to keep up with code reviews and am pretty sure that
> there are maintenance time bombs creeping in all the while.
>
> The only thing that is going to help is more eyes, more people who get
> interested, more people discovering dark corners and doing something
> about them.

+1

> LilyPond needs to get into a state where, say, half the
> engravers are written and maintained in Scheme.  And by "Scheme" I don't
> mean "Scheme at the level Nicolas can barely handle" but "Scheme a
> Fortran programmer would not have all too much of a problem
> understanding".

Umm, impossible?  From my perspective, 'Scheme' and 'easy to
understand' are mutually exclusive.  Unless there are more comments
than code - literally - but we don't do so.

> To get there, we need serious programmers and serious musicians
> interested seriously in LilyPond.  To a level where they start asking
> good questions.  And we better be in a position to provide answers,
> since there is no more effective way to spend our time than on getting
> more people to spend their time, and love, and interest.

That's like + from me!
In general, i agree that we should think in a more 'release-oriented'
way ("last stable release was half a year ago, so we should make
another one, so i'm fixing whatever needs to be fixed to make this
possible") instead of 'free coding' way ("i care about this issue,
i'll fix it.  And that one.  Oh, we have 0 criticals, so let's make a
stable release before an obstruction occurs!").  To do so, we would
have to work more as a team, less independently.  How can we achieve
that if GOP7 showed that we don't want to?

By the way, you mentioned earlier that there are issues much more
severe and threatening to Lily 'stability' than those currently marked
as critical.  This made me curious.  Can you elaborate?

> And we better be in a position to provide answers,
> since there is no more effective way to spend our time than on getting
> more people to spend their time, and love, and interest.

The only "easy" way of moving towards this goal which i see is adding
comments to the code, explaining what it does (and thus making it
easier to provide answers).  Some time ago i was looking at horizontal
spacing code and i didn't understand anything.  I was also recently
trying to make Lily place augmentation dot differently with my friend
Luke (who is, unlike me, a programmer) - it took us a few hours to
figure it out.  I seriously think that Lily code could (and should) be
better described internally.  What do you think?

thanks,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

Janek Warchoł  writes:

> 2012/1/3 David Kastrup :
>> The Learning Guide and the Notation Guide need a complete rereading and
>> reorganization, and it is not like the Extending Guide is in
>> significantly better shape.
>
> I'd like to fix them too, but i don't have time for everything i want
> :(  Splitting my time doesn't look like a good idea - it's more
> effective when i put all my foxus on one thing, analyze it deeply and
> make a complete solution than swap issues.  I have to choose and i
> choose improving graphical output.

I am a TeX specialist, system programmer, Emacs specialist, the GNU
maintainer (and a rather pitiful one) for AUCTeX (lytex and itexi
anybody? preview-latex for Lilypond?), know how to make Emacs read data
from Midi ports, am pretty good concerning compiler writing, shell
scripting, general programming, efficient algorithms, am the resident
quiz person for git and so on and so on.

I would have no problems spending a few hundred man years focused on
Lilypond.  Except that I don't have a few hundred man years.  Nobody
has.  The next best option is spending time on multipliers.  Getting
LilyPond in a shape where passersby find it intriguing, to a degree
where they get hooked and contribute manmonths of work over some time
without having planned to do so at the start.

LilyPond has great infrastructure: it makes by far the most from Texinfo
from any application I know, with much better HTML than upstream, far
more thorough and good use of images (only useful in HTML or with Emacs
as info reader, I am afraid).  I have no clue why or how GUB works, but
many others don't have something like that.  It has good facilities for
internationalization.  There are other novel pieces that turn out to be
more of a maintenance problem than an asset because of a total lack of
documentation and/or mindshare: yaffut, the organization of the C++
core, many internals, stepmake, ...  Many corners are lying dormant
since their respective driving force went away or lost interest or time.

I don't manage to keep up with code reviews and am pretty sure that
there are maintenance time bombs creeping in all the while.

The only thing that is going to help is more eyes, more people who get
interested, more people discovering dark corners and doing something
about them.  LilyPond needs to get into a state where, say, half the
engravers are written and maintained in Scheme.  And by "Scheme" I don't
mean "Scheme at the level Nicolas can barely handle" but "Scheme a
Fortran programmer would not have all too much of a problem
understanding".

To get there, we need serious programmers and serious musicians
interested seriously in LilyPond.  To a level where they start asking
good questions.  And we better be in a position to provide answers,
since there is no more effective way to spend our time than on getting
more people to spend their time, and love, and interest.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Janek Warchoł]

2012/1/3 Graham Percival :
> It so happens that none of these Critical issues are really
> fixable by reverting a single commit.
>
> [...]

ok, thanks for this explanation!

>> Is finding them an easy (no knowledge
>> needed, a complete set of dumbed-down instructions can be given) task
>> that can be done using a moderately fast computer running lilydev (1,5
>> GB RAM for virtual machine, processor Core i5 2.5 GHz and no idea if
>> multicore thingy translates to virtual machine)?
>
> when the problem *is* in the lilypond code base, yes it's
> brain-dead easy to identify the problematic commit.  Instructions
> are already in the CG -- look in the "regressions" chapter.

Silly me, i forgot about that.


2012/1/3 David Kastrup :
> The Learning Guide and the Notation Guide need a complete rereading and
> reorganization, and it is not like the Extending Guide is in
> significantly better shape.

I'd like to fix them too, but i don't have time for everything i want
:(  Splitting my time doesn't look like a good idea - it's more
effective when i put all my foxus on one thing, analyze it deeply and
make a complete solution than swap issues.  I have to choose and i
choose improving graphical output.

>> I can even imagine that well announced release candidates for a new
>> stable version attracts developers to help fix issues with problematic
>> platforms.
>
> If you take a look at Ubuntu release candidates, they usually start with
> a list of "caveats" concerning computers and applications that won't run
> at all.  You need to _start_ with the work for cutting out a release
> before it is magically finished.

Indeed this looks like a good point.

Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

James  writes:

> Hello,
>
> On 3 January 2012 12:53, Han-Wen Nienhuys  wrote:
>> On Tue, Jan 3, 2012 at 10:36 AM, Werner LEMBERG  wrote:
 If we refuse thinking about stable releases by taking GUB as an
 excuse, the grand next stable release that will benefit users of
 many operating systems is likely to fall in the class "too little,
 too late".
>>>
>>> I second David.  Given that we develop within a GNU environment, bugs
>>> specific to Windows and Mac shouldn't prevent stable releases.  I can
>>> even imagine that well announced release candidates for a new stable
>>> version attracts developers to help fix issues with problematic
>>> platforms.
>>
>> From a support perspective, not releasing the windows and mac versions
>> at the same time is problematic.  Many questions and bugreports that
>> could be answered with "upgrade to the latest version" all of a sudden
>> start depending on the platform that the user is using.
>
> Yes, Han-Wen beat me to that point.
>
> So if 2.14 works on OSX but 2.16 doesn't then the user has no choice
> but to stick with 2.14 or use a 2.15 branch both which are no no
> longer being developed.

Newsflash: 2.16 does not work on OSX.  Nor does it work on any other
platform.  The user has no choice but to stick with 2.14 or use a 2.15
branch which does not apparently work on OSX.

> That is a pain to troubleshoot
>
> There is some wonderful work gone into 2.15 that isn't (and never will
> be in 2.14) that the user-base will miss out on.

Newsflash: it is already missing out.

> As a side note, I came to LP via MacOS X + Lilypad, and ran with
> windows only because it is my OS at work. Now I use Linux for all my
> LP work and LilyDev in a VM for Dev and doc work (so LilyPond-Book is
> not a problem for me and having LilyDev in a VM even if it is in a
> Linux OS itself - allows me to use VBox's snapshot for testing or
> reverting when I run into git issues or build issues), in fact my
> Windows LP work is virtually nil now, unless a user or dev asks for
> some second verification.

This does not exactly make a strong point about the ability of Windows
to attract development.

> My question to David, because I am not getting where the 'ire' is
> coming from, why do you care if we release dev after dev release vs
> stable?

http://xkcd.com/386/>

If we look beyond that personality trait, I have a financial interest in
LilyPond becoming a package attractive to people with more money than
programming skills.  A stable release for which the stability and
usability aim is more than just "mostly works on OSX and Windows" would
be helpful to point to.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

Han-Wen Nienhuys  writes:

> On Tue, Jan 3, 2012 at 10:36 AM, Werner LEMBERG  wrote:
>>> If we refuse thinking about stable releases by taking GUB as an
>>> excuse, the grand next stable release that will benefit users of
>>> many operating systems is likely to fall in the class "too little,
>>> too late".
>>
>> I second David.  Given that we develop within a GNU environment, bugs
>> specific to Windows and Mac shouldn't prevent stable releases.  I can
>> even imagine that well announced release candidates for a new stable
>> version attracts developers to help fix issues with problematic
>> platforms.
>
> From a support perspective, not releasing the windows and mac versions
> at the same time is problematic.  Many questions and bugreports that
> could be answered with "upgrade to the latest version" all of a sudden
> start depending on the platform that the user is using. Also, it makes
> it more difficult to get users to pay for work, since users won't pay
> if you don't release the work to their platform

Which is exactly the situation that we find ourselves in already.

> I fully sympathize with the desire to junk Mac and Windows for being a
> pains in the asses to develop for, but they are the platforms where
> the majority of the users are. We (Jan and I) made a conscious
> decision that having more users is better for lilypond than saving
> some developer resources over not distributing windows/mac binaries.

Sure, but we are not talking about junking Mac and Windows, but about
junking using them as a cheap excuse for losing sight of stable release
criteria altogether.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

"m...@apollinemike.com"  writes:

> One in-the-middle approach is to check out package managers that are
> offering LilyPond releases.  I know, for example, that brew offers a
> version of LilyPond on Mac OS X.  If we provide a list of package
> managers and how-tos for the techno-phobic, that may be enough to
> maintain (and even grow) the user base.  It has the added benefit of
> pointing people to better resources than those we could maintain
> in-house: I think that jEdit plus the brew version of LilyPond, for
> example, is a more compelling package than the GUI we distribute.

It sounds to me like Frescobaldi might be a nice base for a good total
package for systems with GUI-centric use patterns.  I have looked at
neither LilyPondTool nor Frescobaldi myself (GUIs are totally not my
thing), but maintaining a compelling GUI/editing package requires a
constant and focused effort, and I have the vague impression that
Frescobaldi is maintained with more of a "core vengeance" rather than an
addon spirit.

Emacs could be a nice package as well since its info reader beats every
other Lilypond information system hollow (unless you get precompiled
info files without included images in which case it is mostly
pointless), but its support of ly and lytex (and, to a degree, itexi) is
not as strong as to put it solidly ahead of the glorified duct tape
class.  Tying lytex, ly, and itexi into the AUCTeX machinery would make
a very impressive offering, but that would entail quite a bit of work.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[James]

Hello,

On 3 January 2012 12:53, Han-Wen Nienhuys  wrote:
> On Tue, Jan 3, 2012 at 10:36 AM, Werner LEMBERG  wrote:
>>> If we refuse thinking about stable releases by taking GUB as an
>>> excuse, the grand next stable release that will benefit users of
>>> many operating systems is likely to fall in the class "too little,
>>> too late".
>>
>> I second David.  Given that we develop within a GNU environment, bugs
>> specific to Windows and Mac shouldn't prevent stable releases.  I can
>> even imagine that well announced release candidates for a new stable
>> version attracts developers to help fix issues with problematic
>> platforms.
>
> From a support perspective, not releasing the windows and mac versions
> at the same time is problematic.  Many questions and bugreports that
> could be answered with "upgrade to the latest version" all of a sudden
> start depending on the platform that the user is using.

Yes, Han-Wen beat me to that point.

So if 2.14 works on OSX but 2.16 doesn't then the user has no choice
but to stick with 2.14 or use a 2.15 branch both which are no no
longer being developed.

That is a pain to troubleshoot

There is some wonderful work gone into 2.15 that isn't (and never will
be in 2.14) that the user-base will miss out on.

>
>> Given that we develop within a GNU environment, bugs
>> specific to Windows and Mac shouldn't prevent stable releases
>
> I don't see how this reasoning works. You do stable releases for
> users, not developers.

Beautifully put.

As a side note, I came to LP via MacOS X + Lilypad, and ran with
windows only because it is my OS at work. Now I use Linux for all my
LP work and LilyDev in a VM for Dev and doc work (so LilyPond-Book is
not a problem for me and having LilyDev in a VM even if it is in a
Linux OS itself - allows me to use VBox's snapshot for testing or
reverting when I run into git issues or build issues), in fact my
Windows LP work is virtually nil now, unless a user or dev asks for
some second verification.

My question to David, because I am not getting where the 'ire' is
coming from, why do you care if we release dev after dev release vs
stable?

-- 
--

James

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

Werner LEMBERG  writes:

>> If we refuse thinking about stable releases by taking GUB as an
>> excuse, the grand next stable release that will benefit users of
>> many operating systems is likely to fall in the class "too little,
>> too late".
>
> I second David.  Given that we develop within a GNU environment, bugs
> specific to Windows and Mac shouldn't prevent stable releases.

The problem is not that bugs specific to Windows and Mac would be
preventing stable releases.  The problem is that we have a _number_ of
problems preventing a stable release, and we are not addressing them
because Mac and Windows provide a convenient excuse.

The Learning Guide and the Notation Guide need a complete rereading and
reorganization, and it is not like the Extending Guide is in
significantly better shape.  There are only few languages for which the
translations can be considered maintained.

Stuff like that picks up considerably after stable releases since the
motivation to help with documenting something that will take years
before the helper gets to see it (and fresh blood tends to get started
on stable releases) is limited.

> I can even imagine that well announced release candidates for a new
> stable version attracts developers to help fix issues with problematic
> platforms.

If you take a look at Ubuntu release candidates, they usually start with
a list of "caveats" concerning computers and applications that won't run
at all.  You need to _start_ with the work for cutting out a release
before it is magically finished.

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Han-Wen Nienhuys]

On Tue, Jan 3, 2012 at 10:36 AM, Werner LEMBERG  wrote:
>> If we refuse thinking about stable releases by taking GUB as an
>> excuse, the grand next stable release that will benefit users of
>> many operating systems is likely to fall in the class "too little,
>> too late".
>
> I second David.  Given that we develop within a GNU environment, bugs
> specific to Windows and Mac shouldn't prevent stable releases.  I can
> even imagine that well announced release candidates for a new stable
> version attracts developers to help fix issues with problematic
> platforms.

From a support perspective, not releasing the windows and mac versions
at the same time is problematic.  Many questions and bugreports that
could be answered with "upgrade to the latest version" all of a sudden
start depending on the platform that the user is using. Also, it makes
it more difficult to get users to pay for work, since users won't pay
if you don't release the work to their platform

I fully sympathize with the desire to junk Mac and Windows for being a
pains in the asses to develop for, but they are the platforms where
the majority of the users are. We (Jan and I) made a conscious
decision that having more users is better for lilypond than saving
some developer resources over not distributing windows/mac binaries.

> Given that we develop within a GNU environment, bugs
> specific to Windows and Mac shouldn't prevent stable releases

I don't see how this reasoning works. You do stable releases for
users, not developers.

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[m...@apollinemike.com]

On Jan 3, 2012, at 1:36 PM, Werner LEMBERG wrote:

> 
>> If we refuse thinking about stable releases by taking GUB as an
>> excuse, the grand next stable release that will benefit users of
>> many operating systems is likely to fall in the class "too little,
>> too late".
> 
> I second David.  Given that we develop within a GNU environment, bugs
> specific to Windows and Mac shouldn't prevent stable releases.  I can
> even imagine that well announced release candidates for a new stable
> version attracts developers to help fix issues with problematic
> platforms.
> 

One in-the-middle approach is to check out package managers that are offering 
LilyPond releases.  I know, for example, that brew offers a version of LilyPond 
on Mac OS X.  If we provide a list of package managers and how-tos for the 
techno-phobic, that may be enough to maintain (and even grow) the user base.  
It has the added benefit of pointing people to better resources than those we 
could maintain in-house: I think that jEdit plus the brew version of LilyPond, 
for example, is a more compelling package than the GUI we distribute.

Does Windows have its share of package managers that offer this sorta thing?

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Werner LEMBERG]

> If we refuse thinking about stable releases by taking GUB as an
> excuse, the grand next stable release that will benefit users of
> many operating systems is likely to fall in the class "too little,
> too late".

I second David.  Given that we develop within a GNU environment, bugs
specific to Windows and Mac shouldn't prevent stable releases.  I can
even imagine that well announced release candidates for a new stable
version attracts developers to help fix issues with problematic
platforms.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: "Phil Holmes" 


No.  I have an Ubuntu VM which I use for quick experiments and a very
fast Ubuntu PC which I use for full builds.  But I support lilypond
because I _use_ it for typesetting music on a _Windows_ machine. Take
away that ability to use it, and the desire to support goes away.


Yup, and our current effective strategy of not doing stable releases
takes away that ability from anyone.  Not just Windows users.


Personally, I'm quite happy using a development version for my music 
typesetting.  If the most recent one causes a problem, I revert to the 
previous version.



--
David Kastrup




--
Phil Holmes



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

"Phil Holmes"  writes:

> From: "David Kastrup" 
> To: 
> Sent: Tuesday, January 03, 2012 11:44 AM
> Subject: Re: critical issues
>
>> "Phil Holmes"  writes:
>>
>>> From: "David Kastrup" 
>>> To: 
>>>
>>>> There is a _reason_ the remaining OSX and Windows based developers
>>>> are doing (definitely important) documentation and web site work.
>>>> They are to a large degree locked out and dependent on support from
>>>> surplus GNU/Linux-based developer capacities.  We are not doing them
>>>> any favors by killing LilyPond development as a whole out of sympathy
>>>> with their plight.
>>>
>>> Not at all.  I think you know that myself and James are mainly Windows
>>> users.  We also run big Ubuntu machines that support the build
>>> environment. However, we came to the development from being Windows
>>> users.  Cut off that supply and I'll probably stop supporting Lily,
>>> which I would regret.
>>
>> You are compiling your own binaries without using GNU/Linux in the
>> process?
>>
>> That's what a native development environment would look like.
>
> No.  I have an Ubuntu VM which I use for quick experiments and a very
> fast Ubuntu PC which I use for full builds.  But I support lilypond
> because I _use_ it for typesetting music on a _Windows_ machine. Take
> away that ability to use it, and the sesire to support goes away.

Yup, and our current effective strategy of not doing stable releases
takes away that ability from anyone.  Not just Windows users.

>> It is nice that things are not as completely broken as I thought.
>> But I still think that our effectively current philosophy of "the
>> next stable release is something only developers interested in
>> Windows and OSX need to concern themselves with" is doing anybody a
>> favor.  Our road map has nothing to offer beyond GUB, and so there is
>> little interest in getting even there.
>
> I think you've mis-stated the philosophy.  It's "the next stable
> release is something that will benefit users of many operating
> systems, including many flavours of Unix, plus windows and MAC".

That's the vision.  The vision can't replace the road leading to it.
The only roadmap we have is "critical issues", and none of the critical
issues are anything that could be tackled by anybody rather than
developers with quite special skills and interests.  If all of the
critical issues go away over night for some reason, we still have
nothing that can in good conscience be sold as "stable release".  And by
the time we get there, GUB will probably have acquired enough fresh bit
rot that we will be in the same situation as we are now.

If we refuse thinking about stable releases by taking GUB as an excuse,
the grand next stable release that will benefit users of many operating
systems is likely to fall in the class "too little, too late".

-- 
David Kastrup

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: 
Sent: Tuesday, January 03, 2012 11:44 AM
Subject: Re: critical issues



"Phil Holmes"  writes:


From: "David Kastrup" 
To: 


There is a _reason_ the remaining OSX and Windows based developers
are doing (definitely important) documentation and web site work.
They are to a large degree locked out and dependent on support from
surplus GNU/Linux-based developer capacities.  We are not doing them
any favors by killing LilyPond development as a whole out of sympathy
with their plight.


Not at all.  I think you know that myself and James are mainly Windows
users.  We also run big Ubuntu machines that support the build
environment. However, we came to the development from being Windows
users.  Cut off that supply and I'll probably stop supporting Lily,
which I would regret.


You are compiling your own binaries without using GNU/Linux in the
process?

That's what a native development environment would look like.


No.  I have an Ubuntu VM which I use for quick experiments and a very fast 
Ubuntu PC which I use for full builds.  But I support lilypond because I 
_use_ it for typesetting music on a _Windows_ machine. Take away that 
ability to use it, and the sesire to support goes away.



- what does this do to our ONLY documentation writers and
  reviewers (who are all windows-based)?  Will they be a) more
  motivated to work on lilypond, b) no change, or c) less
  motivated?


We are already screwing them over with GNU/Linux-only "developer
releases".  When will we stop using our Windows and OSX developers as
an excuse for not working on a stable release that would actually
warrant the effort of getting GUB working again and matched to
current Windows and OSX releases?


Not true - see above.


Documentation and web writing without a functional lilypond-book strikes
me as somewhat difficult.


I don't use lilypond-book for day-day activity - only lilypond development.


It is nice that things are not as completely broken as I thought.  But I
still think that our effectively current philosophy of "the next stable
release is something only developers interested in Windows and OSX need
to concern themselves with" is doing anybody a favor.  Our road map has
nothing to offer beyond GUB, and so there is little interest in getting
even there.


I think you've mis-stated the philosophy.  It's "the next stable release is 
something that will benefit users of many operating systems, including many 
flavours of Unix, plus windows and MAC".


--
Phil Holmes



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

"Phil Holmes"  writes:

> From: "David Kastrup" 
> To: 
>
>> There is a _reason_ the remaining OSX and Windows based developers
>> are doing (definitely important) documentation and web site work.
>> They are to a large degree locked out and dependent on support from
>> surplus GNU/Linux-based developer capacities.  We are not doing them
>> any favors by killing LilyPond development as a whole out of sympathy
>> with their plight.
>
> Not at all.  I think you know that myself and James are mainly Windows
> users.  We also run big Ubuntu machines that support the build
> environment. However, we came to the development from being Windows
> users.  Cut off that supply and I'll probably stop supporting Lily,
> which I would regret.

You are compiling your own binaries without using GNU/Linux in the
process?

That's what a native development environment would look like.

>>> - what does this do to our ONLY documentation writers and
>>>   reviewers (who are all windows-based)?  Will they be a) more
>>>   motivated to work on lilypond, b) no change, or c) less
>>>   motivated?
>>
>> We are already screwing them over with GNU/Linux-only "developer
>> releases".  When will we stop using our Windows and OSX developers as
>> an excuse for not working on a stable release that would actually
>> warrant the effort of getting GUB working again and matched to
>> current Windows and OSX releases?
>
> Not true - see above.

Documentation and web writing without a functional lilypond-book strikes
me as somewhat difficult.

It is nice that things are not as completely broken as I thought.  But I
still think that our effectively current philosophy of "the next stable
release is something only developers interested in Windows and OSX need
to concern themselves with" is doing anybody a favor.  Our road map has
nothing to offer beyond GUB, and so there is little interest in getting
even there.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Phil Holmes]

- Original Message - 
From: "David Kastrup" 

To: 
Sent: Tuesday, January 03, 2012 7:55 AM
Subject: Re: critical issues



Graham Percival  writes:


On Tue, Jan 03, 2012 at 01:03:08AM +0100, David Kastrup wrote:

Graham Percival  writes:

> We could certainly consider dropping support for OSX or windows.

That sort of token solidarity is actually counterproductive:
if you believe that non-releases lead to non-users,


yes


and you think that
non-releases for GNU/Linux may pressure GNU/Linux developers into making
OSX/Windows releases,


no


then how does a non-release for GNU/Linux, with
its corresponding result in decreasing GNU/Linux users and GNU/Linux
developers, help in recruiting GNU/Linux developers that can be
pressured into making OSX and Windows releases?


it doesn't?


Exactly.


Suppose we announce a big new shiny lilypond 2.16.  For linux and
freebsd only.  OSX and windows users can go screw themselves.


We are not announcing a big new shiny Lilypond 2.16.  We are announcing
big new shiny 2.15.xx "developer" releases one after another.  For
GNU/Linux and FreeBSD only.


N.  I'm happily running pretty much every 2.15 version on my Windows 
box.  It runs fine and it's my normal music-producing environment, and also 
the one on which I test for bugs and get examples to add to the tracker. 
AFAIK the only problem is with lilypond-book, which I personally don't run 
on my windows machine.



OSX and Windows users _are_ second class (or handicapped) citizens for
LilyPond because the whole technology is based on GNU, and since the
developer skills needed to work with it strongly correlate with
UNIX-like systems.  The whole point of GUB is that it is a _cross_
building ennvironment that can be maintained by GNU/Linux developers for
the sake of OSX and Windows users.  The skill level for actively keeping
GUB working (rather than plug and pray) is considerable, and requires
good GNU/Linux (or at least UNIX) skills and at least contact skills
with OSX and Windows.  Without a healthy surplus of GNU/Linux-based
developers that are not already locked down with keeping up their own
projects, our OSX and Windows users can indeed, as you so flowery put
it, can go screw themselves because they can't hope to screw with
LilyPond, rather pure UNIX-based technology requiring UNIX-centric skill
sets and mind frames.

There is a _reason_ the remaining OSX and Windows based developers are
doing (definitely important) documentation and web site work.  They are
to a large degree locked out and dependent on support from surplus
GNU/Linux-based developer capacities.  We are not doing them any favors
by killing LilyPond development as a whole out of sympathy with their
plight.


Not at all.  I think you know that myself and James are mainly Windows 
users.  We also run big Ubuntu machines that support the build environment. 
However, we came to the development from being Windows users.  Cut off that 
supply and I'll probably stop supporting Lily, which I would regret.



- what does this do to our ONLY documentation writers and
  reviewers (who are all windows-based)?  Will they be a) more
  motivated to work on lilypond, b) no change, or c) less
  motivated?


We are already screwing them over with GNU/Linux-only "developer
releases".  When will we stop using our Windows and OSX developers as an
excuse for not working on a stable release that would actually warrant
the effort of getting GUB working again and matched to current Windows
and OSX releases?


Not true - see above.


--
Phil Holmes



___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

Graham Percival  writes:

> On Tue, Jan 03, 2012 at 01:03:08AM +0100, David Kastrup wrote:
>> Graham Percival  writes:
>> 
>> > We could certainly consider dropping support for OSX or windows.
>> 
>> That sort of token solidarity is actually counterproductive:
>> if you believe that non-releases lead to non-users,
>
> yes
>
>> and you think that
>> non-releases for GNU/Linux may pressure GNU/Linux developers into making
>> OSX/Windows releases,
>
> no
>
>> then how does a non-release for GNU/Linux, with
>> its corresponding result in decreasing GNU/Linux users and GNU/Linux
>> developers, help in recruiting GNU/Linux developers that can be
>> pressured into making OSX and Windows releases?
>
> it doesn't?

Exactly.

> Suppose we announce a big new shiny lilypond 2.16.  For linux and
> freebsd only.  OSX and windows users can go screw themselves.

We are not announcing a big new shiny Lilypond 2.16.  We are announcing
big new shiny 2.15.xx "developer" releases one after another.  For
GNU/Linux and FreeBSD only.  And we are not bothering to stabilize
development into a state where it would even make sense to announce 2.16
for anybody.  Or where the effort to bring GUB into release shape would
appear to be worth the trouble.

OSX and Windows users _are_ second class (or handicapped) citizens for
LilyPond because the whole technology is based on GNU, and since the
developer skills needed to work with it strongly correlate with
UNIX-like systems.  The whole point of GUB is that it is a _cross_
building ennvironment that can be maintained by GNU/Linux developers for
the sake of OSX and Windows users.  The skill level for actively keeping
GUB working (rather than plug and pray) is considerable, and requires
good GNU/Linux (or at least UNIX) skills and at least contact skills
with OSX and Windows.  Without a healthy surplus of GNU/Linux-based
developers that are not already locked down with keeping up their own
projects, our OSX and Windows users can indeed, as you so flowery put
it, can go screw themselves because they can't hope to screw with
LilyPond, rather pure UNIX-based technology requiring UNIX-centric skill
sets and mind frames.

There is a _reason_ the remaining OSX and Windows based developers are
doing (definitely important) documentation and web site work.  They are
to a large degree locked out and dependent on support from surplus
GNU/Linux-based developer capacities.  We are not doing them any favors
by killing LilyPond development as a whole out of sympathy with their
plight.

> - what does this do to our ONLY documentation writers and
>   reviewers (who are all windows-based)?  Will they be a) more
>   motivated to work on lilypond, b) no change, or c) less
>   motivated?

We are already screwing them over with GNU/Linux-only "developer
releases".  When will we stop using our Windows and OSX developers as an
excuse for not working on a stable release that would actually warrant
the effort of getting GUB working again and matched to current Windows
and OSX releases?

> I will admit that the latter point could be construed as "if we
> make it very difficult to contribute to lilypond, then I'm going
> to punish everybody by not having stable releases" -- but almost
> all of those "can't-contribute" bugs can be fixed in an hour or
> two, and is platform-independent (or rather: it only involves
> lilydev, which is ubuntu, most often inside virtualbox, so anybody
> can work on that).

Newsflash: "anybody" needs considerable GNU/Linux skills to work on
that.  And extra time.  Why should he bother when he can just go on
working with "development releases" on GNU/Linux?

I don't see GUB catching up without having a feature freeze, the freeze
associated with starting a stable release cycle.  A freeze that actually
_stops_ the releases labelled as "development" releases in order to hide
the fact that we have stopped actually catering to Windows and OSX users
years ago.  They need actions, not warm wishes and self-flagellation.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Tue, Jan 03, 2012 at 06:24:19AM +0100, Janek Warchoł wrote:
> By the way, do we have a policy about regressions?

Yes, they're bad?  :)

> I remember that
> reverting bad commits was discussed in the past, and i'm quite for
> this solution.
> I don't see information about which commits caused our currently open
> critical regression, does it mean that's impossible to tell or simply
> noone tried to find them?

It so happens that none of these Critical issues are really
fixable by reverting a single commit.

- lilypond-book came from a general rewrite of lilypond-book.
- osx came from me accepting a GUB patch which had a problem,
  which technically we could revert but it's better to just solve
  the underlying problem.  (and in fact I think it *has* been
  solved)
- windows path isn't strictly a regression, but IMO it screws up
  users' systems in a sufficiently stupid and embarrassing way
  that I'm going to call it Critical anyway.
- git branches comes from staging, which is necessary because
  people kept on breaking git master.
- web-git came from a cleanup of the old website, originating from
  a build system patch of mine, but come on folks, we already have
  a patch for this in the system, don't complain about that issue.

> Is finding them an easy (no knowledge
> needed, a complete set of dumbed-down instructions can be given) task
> that can be done using a moderately fast computer running lilydev (1,5
> GB RAM for virtual machine, processor Core i5 2.5 GHz and no idea if
> multicore thingy translates to virtual machine)?

when the problem *is* in the lilypond code base, yes it's
brain-dead easy to identify the problematic commit.  Instructions
are already in the CG -- look in the "regressions" chapter.

Cheers
,- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Janek Warchoł]

(sorry for double-post)

2012/1/2 Graham Percival :
> On Mon, Jan 02, 2012 at 10:23:28PM +0100, David Kastrup wrote:
>> Graham Percival  writes:
>> > If you are aware of any other issues which fall under the
>> > definition (i.e. a reproducible failure to build lilypond from
>> > scratch,
>>
>> On a supported platform.  It does not look like there is currently much
>> sense in calling MacOSX or Windows that.
>
> The exact details of the proposal specifies "as long as configure
> reports no problems", which presumably would fail on osx (unless
> it was highly tweaked) or windows.
>
>> > an unintentional regression, or something which stops a good
>> > contributor from working on lilypond),
>>
>> That's urgent.  But it is not release-relevant since good contributors
>> don't work on released versions but on the development version.  I also
>> see no point in delaying a stable release because of details that are
>> not actually worse than at the previous release.
>
> I understand your point of view.  However, that was not the
> decision that we reached during that GOP discussion, and I am not
> interested in re-opening that discussion.
>
> Bottom line: I will not be calling anything a "stable release", or
> even a "release candidate", if there are issues which are known to
> fall under the current definition of a "Critical issue".  I am not
> open to changing that definition for at least the next 6 months.
> However, lilypond is open-source software; there are no legal
> barriers[1] to other people building binaries and distributing
> them under whatever name they wanted[2].

By the way, do we have a policy about regressions?  I remember that
reverting bad commits was discussed in the past, and i'm quite for
this solution.
I don't see information about which commits caused our currently open
critical regression, does it mean that's impossible to tell or simply
noone tried to find them?  Is finding them an easy (no knowledge
needed, a complete set of dumbed-down instructions can be given) task
that can be done using a moderately fast computer running lilydev (1,5
GB RAM for virtual machine, processor Core i5 2.5 GHz and no idea if
multicore thingy translates to virtual machine)?

cheers,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Janek Warchoł]

2012/1/3 David Kastrup :
> I am afraid that we are painting ourselves into a corner.  And I don't
> think that we are doing ourselves a favor by defining "stable" as "a
> random moment when somebody managed to get GUB to run for Windows and
> OSX".  We should define "stable" based on the stability and state of the
> _actively_ happening development.  _That's_ what we should be cutting
> the stable branch from.  And _then_ try getting it ported timely to the
> platforms that have, lamentably, a rather lacklustre progress of
> releasable material and platform-specific development.  I see very
> little correlation between what I'd call a measure of stability, and
> what the current set of "Critical bugs" entails.

While this sounds reasonable, i'm not sure if a policy could be
written that would reflect your intentions; they're a bit too vague.
And even with current guidelines its always possible to say "i think
that we shouldn't make a stable release despite having 0 critical
issues, because current master is shabby and we have some major
changes going in the codebase".

I think that the problem may be that we don't organize our work (and
don't want to according to GOP7
http://lilypond.org/~graham/gop/gop_7.html).  In fact, we work quite
like a bunch of individuals doing really independent things all the
time; there are little to no efforts like "guys, let's fix that ".

Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Tue, Jan 03, 2012 at 01:03:08AM +0100, David Kastrup wrote:
> Graham Percival  writes:
> 
> > We could certainly consider dropping support for OSX or windows.
> 
> That sort of token solidarity is actually counterproductive:
> if you believe that non-releases lead to non-users,

yes

> and you think that
> non-releases for GNU/Linux may pressure GNU/Linux developers into making
> OSX/Windows releases,

no

> then how does a non-release for GNU/Linux, with
> its corresponding result in decreasing GNU/Linux users and GNU/Linux
> developers, help in recruiting GNU/Linux developers that can be
> pressured into making OSX and Windows releases?

it doesn't?


Suppose we announce a big new shiny lilypond 2.16.  For linux and
freebsd only.  OSX and windows users can go screw themselves.

- what does this do to our ONLY documentation writers and
  reviewers (who are all windows-based)?  Will they be a) more
  motivated to work on lilypond, b) no change, or c) less
  motivated?
- what does this do to our active developers, approximately half
  of which are on OSX?  Will they be a) b) or c) ?


> And I don't think that we are doing ourselves a favor by
> defining "stable" as "a random moment when somebody managed to
> get GUB to run for Windows and OSX".

Good news, we're not.  We're definining "stable" as "is not
deliberately worse than the previous release, for all platforms
which we officially release for".  Plus a little bit of "... and
we can reasonably expect a reasonable contributor to be able to
contribute".

I will admit that the latter point could be construed as "if we
make it very difficult to contribute to lilypond, then I'm going
to punish everybody by not having stable releases" -- but almost
all of those "can't-contribute" bugs can be fixed in an hour or
two, and is platform-independent (or rather: it only involves
lilydev, which is ubuntu, most often inside virtualbox, so anybody
can work on that).

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

Graham Percival  writes:

> On Mon, Jan 02, 2012 at 10:23:28PM +0100, David Kastrup wrote:
>> Graham Percival  writes:
>> 
>> > This was the result of between 25 to 40 emails in August 2011 on
>> > lilypond-devel.  A quick scan didn't reveal your name amongst
>> > those emails, but we simply cannot afford to revisit every policy
>> > decision every six months because somebody didn't notice or wasn't
>> > interested in the previous discussion.
>> 
>> The labels are not all that interesting to me.  If we don't have
>> developers or users interested in working seriously on or with certain
>> proprietary platforms, then there is no point in calling those platforms
>> supported and stopping the release process for those platforms that
>> _can_ be considered supported.
>
> We could certainly consider dropping support for OSX or windows.

Stopping releases on GNU/Linux is doing as much for supporting OSX or
Windows as throwing away your supper is doing for supporting starving
children.  That sort of token solidarity is actually counterproductive:
if you believe that non-releases lead to non-users, and you think that
non-releases for GNU/Linux may pressure GNU/Linux developers into making
OSX/Windows releases, then how does a non-release for GNU/Linux, with
its corresponding result in decreasing GNU/Linux users and GNU/Linux
developers, help in recruiting GNU/Linux developers that can be
pressured into making OSX and Windows releases?

> That would eliminate 80% (or more!) of our user base, including
> everybody who works on our documentation, plus certain extremely
> valuable developer like Carl... but I suppose that, logically
> speaking, we could consider it.
>
> I am against that idea.

Even if we assume that GNU/Linux releases don't help keeping and gaining
OSX and Windows users, this does not imply that not making GNU/Linux
releases helps keeping and gaining OSX and Windows users.

I am afraid that we are painting ourselves into a corner.  And I don't
think that we are doing ourselves a favor by defining "stable" as "a
random moment when somebody managed to get GUB to run for Windows and
OSX".  We should define "stable" based on the stability and state of the
_actively_ happening development.  _That's_ what we should be cutting
the stable branch from.  And _then_ try getting it ported timely to the
platforms that have, lamentably, a rather lacklustre progress of
releasable material and platform-specific development.  I see very
little correlation between what I'd call a measure of stability, and
what the current set of "Critical bugs" entails.

> Bottom line: I will not be calling anything a "stable release", or
> even a "release candidate", if there are issues which are known to
> fall under the current definition of a "Critical issue".  I am not
> open to changing that definition for at least the next 6 months.

And nobody feels a need to worry about stability if "stable" is not
expected to be around the corner anytime soon for reasons out of his
control (you can't expect people working all too much for systems they
do not even have available for testing purposes).

This is not actually supposed to be a discussion from my side.  It's
more like head-scratching.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Janek Warchoł]

2012/1/2 Graham Percival :
> On Mon, Jan 02, 2012 at 10:23:28PM +0100, David Kastrup wrote:
>> Graham Percival  writes:
>>
>> > This was the result of between 25 to 40 emails in August 2011 on
>> > lilypond-devel.  A quick scan didn't reveal your name amongst
>> > those emails, but we simply cannot afford to revisit every policy
>> > decision every six months because somebody didn't notice or wasn't
>> > interested in the previous discussion.
>>
>> The labels are not all that interesting to me.  If we don't have
>> developers or users interested in working seriously on or with certain
>> proprietary platforms, then there is no point in calling those platforms
>> supported and stopping the release process for those platforms that
>> _can_ be considered supported.

I'm seriously interested in using Lily on Windows.  Unfortunately
issues 1933 and 1948 are quite beyond me; i don't even understand what
is written in 1933.  I could try attacking 1948, however, this sounds
like 10+ hours of set-up work and 20+ emails *before* actual fixing
can happen (for my experience level).  I'd prefer to use this time to
do something i'm good at: fixing small things (i'm restoring my
lilydev after three-months pause) and writing well-documented and
cross-linked issues for our tracker (recently i wrote issues
2141-2145, it was really a lot of work to gather all examples and
separate the whole "accidental problem" into separate, yet meaningful,
issues).
If you think that i really should attack these critical issues at all
costs, let me know and i'll consider it.

> We could certainly consider dropping support for OSX or windows.
> That would eliminate 80% (or more!) of our user base, including
> everybody who works on our documentation, plus certain extremely
> valuable developer like Carl... but I suppose that, logically
> speaking, we could consider it.
>
> I am against that idea.

+1

I'm also against making a Linux-only release.  While technically
possible, it would introduce a high level of mess.

>> > an unintentional regression, or something which stops a good
>> > contributor from working on lilypond),
>>
>> That's urgent.  But it is not release-relevant since good contributors
>> don't work on released versions but on the development version.  I also
>> see no point in delaying a stable release because of details that are
>> not actually worse than at the previous release.

Well, i think that this was Graham's desperate try to get us more
involved in maintainability issues.  I support that and i'll look at
issue 2100 as fast as possible,

cheers,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Mon, Jan 02, 2012 at 10:23:28PM +0100, David Kastrup wrote:
> Graham Percival  writes:
> 
> > This was the result of between 25 to 40 emails in August 2011 on
> > lilypond-devel.  A quick scan didn't reveal your name amongst
> > those emails, but we simply cannot afford to revisit every policy
> > decision every six months because somebody didn't notice or wasn't
> > interested in the previous discussion.
> 
> The labels are not all that interesting to me.  If we don't have
> developers or users interested in working seriously on or with certain
> proprietary platforms, then there is no point in calling those platforms
> supported and stopping the release process for those platforms that
> _can_ be considered supported.

We could certainly consider dropping support for OSX or windows.
That would eliminate 80% (or more!) of our user base, including
everybody who works on our documentation, plus certain extremely
valuable developer like Carl... but I suppose that, logically
speaking, we could consider it.

I am against that idea.

> > If you are aware of any other issues which fall under the
> > definition (i.e. a reproducible failure to build lilypond from
> > scratch,
> 
> On a supported platform.  It does not look like there is currently much
> sense in calling MacOSX or Windows that.

The exact details of the proposal specifies "as long as configure
reports no problems", which presumably would fail on osx (unless
it was highly tweaked) or windows.

> > an unintentional regression, or something which stops a good
> > contributor from working on lilypond),
> 
> That's urgent.  But it is not release-relevant since good contributors
> don't work on released versions but on the development version.  I also
> see no point in delaying a stable release because of details that are
> not actually worse than at the previous release.

I understand your point of view.  However, that was not the
decision that we reached during that GOP discussion, and I am not
interested in re-opening that discussion.

Bottom line: I will not be calling anything a "stable release", or
even a "release candidate", if there are issues which are known to
fall under the current definition of a "Critical issue".  I am not
open to changing that definition for at least the next 6 months.
However, lilypond is open-source software; there are no legal
barriers[1] to other people building binaries and distributing
them under whatever name they wanted[2].

[1] other than trademark law.
[2] common practice in open-source software is to release "forked"
software under a different name than the original to avoid
confusion, but I doubt that this is a legal requirement.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

Graham Percival  writes:

> On Mon, Jan 02, 2012 at 09:59:47PM +0100, David Kastrup wrote:
>> 
>> I see the following critical issues:
> -snip-
>> 
>> There is, actually, a wagonload of other changes underfoot that does not
>> appear quite compatible with releasing a version called "stable" to me.
>> It seems strange to me that the _above_ should be the critical ones.
>> Critical enough that we don't even bother with trying to stabilize the
>> remaining situation.
>
> The definition of a Critical issue is given here:
> http://lilypond.org/doc/v2.15/Documentation/contributor/gop_002dprop-8-_002d-issue-priorities
>
> This was the result of between 25 to 40 emails in August 2011 on
> lilypond-devel.  A quick scan didn't reveal your name amongst
> those emails, but we simply cannot afford to revisit every policy
> decision every six months because somebody didn't notice or wasn't
> interested in the previous discussion.

The labels are not all that interesting to me.  If we don't have
developers or users interested in working seriously on or with certain
proprietary platforms, then there is no point in calling those platforms
supported and stopping the release process for those platforms that
_can_ be considered supported.

> If you are aware of any other issues which fall under the
> definition (i.e. a reproducible failure to build lilypond from
> scratch,

On a supported platform.  It does not look like there is currently much
sense in calling MacOSX or Windows that.

> an unintentional regression, or something which stops a good
> contributor from working on lilypond),

That's urgent.  But it is not release-relevant since good contributors
don't work on released versions but on the development version.  I also
see no point in delaying a stable release because of details that are
not actually worse than at the previous release.

> then please change that issue to be Type-Critical instead of whatever
> it is right now.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Mon, Jan 02, 2012 at 09:59:47PM +0100, David Kastrup wrote:
> 
> I see the following critical issues:
-snip-
> 
> There is, actually, a wagonload of other changes underfoot that does not
> appear quite compatible with releasing a version called "stable" to me.
> It seems strange to me that the _above_ should be the critical ones.
> Critical enough that we don't even bother with trying to stabilize the
> remaining situation.

The definition of a Critical issue is given here:
http://lilypond.org/doc/v2.15/Documentation/contributor/gop_002dprop-8-_002d-issue-priorities

This was the result of between 25 to 40 emails in August 2011 on
lilypond-devel.  A quick scan didn't reveal your name amongst
those emails, but we simply cannot afford to revisit every policy
decision every six months because somebody didn't notice or wasn't
interested in the previous discussion.


If you are aware of any other issues which fall under the
definition (i.e. a reproducible failure to build lilypond from
scratch, an unintentional regression, or something which stops a
good contributor from working on lilypond), then please change
that issue to be Type-Critical instead of whatever it is right
now.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Sun, Jan 23, 2011 at 10:29:11AM -0500, Boris Shingarov wrote:
> The Lilypond project has a very specific set of objectives.  There
> is a defined set of procedures, a roadmap, a set of criteria of
> what is acceptable to go into the codebase, etc.

This is true of any (well-organized) project.

> When these rules contradict Lilypond rules, I
> follow the history research project's rules, not the Lilypond
> project's rules, because it is the music history research project
> that pays me.

That is entirely appropriate.  :)

> What they (and
> your Norwegian friends with their 17th century songs) care about,
> is whether or not it is possible to typeset Norwegian lyrics.
> Which it isn't -- and it's not even Lilypond's fault: SRFI-13
> in Guile does not work with Unicode.

eh?  We've had utf-8 lyrics for a while.  Anyway, that's an aside.

> So we have all this work done, but it would be an even bigger
> effort to merge it back.

This is a general problem with all software projects --
commercial, open source, in-house, world-wide, etc.  I've read
comments on programming forums or blogs saying that it takes 5
times the effort to merge something upstream than it does to
implement it in the first place.  There's lots of discussion
online about sending linux kernel patches upstream, or gcc
patches, etc.

> However, I am making aggressive steps to change this.  As we
> attract more attention from serious organizations, we get into
> position to bring forward some conditions for the next project.
> Namely, it will become imperative that all contributions get
> merged back into the community codebase.

Yes.

Basically, it's a trade-off.  If you work by yourself (or with a
small group of programmers), you can do whatever you want.  Focus
on just the features you want, break other stuff, use shortcuts
that could potentially cause problems later on but aren't relevant
yet, etc.  There's nothing wrong with this -- I work in this
manner quite often on my own personal research projects.

However, if you work by yourself, then it's more difficult to
share your code with other people (if you want to), and you can't
get improvements that other people have made (if you care about
those).

Now, in your case, your group doesn't care about piano music or
orchestra stuff.  That's totally fine!  But what if the guile 2.0
change could speed up your processing?  Or maybe your group could
benefit from Benko Pal's "black mensural notation and coloratio in
white mensural notation" work?  Well, the more your source tree
diverges from the main lilypond git tree, the harder it will be to
get those changes.


*shrug*
I'm not saying that it's worth trying to merge your patches.
That's really a question of how much work you want to do on
general maintenance, how long you think your group will be working
on this projects (or related future ones), etc etc.  In the very
long term, I think that merging things with main git will be less
work.  Once we accept a patch, we'll turn down other patches that
break your features, so that aspect of maintenance is now *our*
problem (or the next patch submitter's problem), not yours.

However, by "very long term", I'm thinking "5-10 years".  If
you're only doing a 2-year project, with regular deadlines, and
don't expect to be doing anything else like this after 2 years,
then I honestly think it would be irrational of you to spend
time+effort merging patches with main lilypond git.


As you know, we're trying to make it easier for contributors,
easier to discuss+merge new features, etc., but it's not an easy
process  If it's not worth merging stuff now, it might still be
worth it in 6 months.  This is really a question between you and
the people who sign your paychecks... another option might be to
allocate a short amount of time (say, 2 hours a week?) to spend on
merging patches.  That way, at least you (and your bosses) know
how much time you'll lose on this task.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Boris Shingarov]

On 11-01-01 03:24 AM, Graham Percival wrote:

or an
art history / research grant.  I think the latter is more
likely... for example, if somebody got a grant to typeset 17th
century Norweigan folk songs, and decided to use lilypond, and
spent x% of the grant towards "improving community-oriented tools
for folk music archival", etc.

This is exactly what we have been doing here for a while.  In
act, it absolutely amazes me how closely you are describing our
project.  Only 100 years off (16th century instead of 17th),
and only a few hundred kilometers off.

But as I was trying to explain last summer, there are some problems.

The Lilypond project has a very specific set of objectives.  There
is a defined set of procedures, a roadmap, a set of criteria of
what is acceptable to go into the codebase, etc.

The music history research project, has its own set of objectives.
And its own set of rules.  And procedures.  And criteria of what
is acceptable.  When these rules contradict Lilypond rules, I
follow the history research project's rules, not the Lilypond
project's rules, because it is the music history research project
that pays me.  How contradictory are these rules, and how big is
the problem?

Well on one hand, none of today's Critical Issues in Lilypond,
are on the list of priorities for our project.  So even if we had
20 full-time developers, it wouldn't help with releasing the next
stable version.

On the other hand, we have implemented some major new
functionality.  Seamless markup-to-embedded-score integration,
automatic endnotes, merging and visual indication of used sources,
and a lot of other things.  Can it be contributed back?  Hardly
in its current form.  It causes a ton of regressions: basically,
it does not work on anything but Gregorian plainchant.  It will
immediately crash on any piano music or orchestral music.  Will
I fix it?  Not unless someone pays me to, and I know the music
historians will not, because they don't care.  What they (and
your Norwegian friends with their 17th century songs) care about,
is whether or not it is possible to typeset Norwegian lyrics.
Which it isn't -- and it's not even Lilypond's fault: SRFI-13
in Guile does not work with Unicode.

So we have all this work done, but it would be an even bigger
effort to merge it back.  Who will do it?  In the current
situation, I don't know.

However, I am making aggressive steps to change this.  As we
attract more attention from serious organizations, we get into
position to bring forward some conditions for the next project.
Namely, it will become imperative that all contributions get
merged back into the community codebase.  It still does not
mean helping with things like releasing the next stable version
of Lilypond, or similarly, with any part of Lilypond agenda;
although I am not sure if it is a bad thing -- if we want to
transition from being "a volunteer project with limited
resources" to "professional open-source", we will need to face
the fact that there are things which customers are willing to
pay for, and things which no-one finds important enough to
either work on themselves or pay for.

But first we will have to be successful to engage in the new
project.  It is still unclear whether it will happen or not.
I will keep you posted.

Boris



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Mon, Jan 03, 2011 at 01:14:19PM -, Phil Holmes wrote:
> version, but this looks fine."  My intention was that, even if it
> was a minor bug, then someone had put work in recently to fix it.
> If someone else has just unpicked that, then this a Bad Thing and
> should be corrected.

I don't want to get bogged down with policy discussions right now;
let's postpone this discussion until after 2.14.  I've added it to
the GOP policy question list (along with other important
questions).

Go ahead and get your patch for
http://lists.gnu.org/archive/html/lilypond-devel/2011-01/msg00053.html

As long as there's the "... can be subject ot change by the
development team", I think there's no short-term problem, and any
long-term issues are highly connected to other questions (like
"how often do we want stable releases" and "how picky should we be
with patches") that we're also postponing until after 2.14.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Phil Holmes]

- Original Message - 
From: "Graham Percival" 

To: "Phil Holmes" 
Cc: 
Sent: Monday, January 03, 2011 3:15 AM
Subject: Re: critical issues



On Sun, Jan 02, 2011 at 04:37:35PM -, Phil Holmes wrote:

"
Priority-Critical: LilyPond segfaults, a regression (see below)
against a previous stable version or a regression against a fix
developed for this version. This does not apply where the
"regression" occurred because a feature was removed deliberately -
this is not a bug.
"


I'm not certain what "regression against a fix developed for this
version" means.  If somebody fixes a minor bug in 2.13.15, and
that fix doesn't work in 2.13.17, I don't think that should be a
Critical bug.  If the fix works in 2.14.0 but doesn't work in
2.14.2 or 2.15.2, then I _would_ consider that a critical bug,
under the usual "regression against the past two stable versions"
rule.


That was new wording I was under the impression we'd agreed the last time 
this was discussed.  You said "I can't tell if there was a difference here 
from the current
version, but this looks fine."  My intention was that, even if it was a 
minor bug, then someone had put work in recently to fix it.  If someone else 
has just unpicked that, then this a Bad Thing and should be corrected.



At the bottom of this section, add:
"
Note that these are initial classifications and can be subject to
change by others in the development team.  For example, a regression
against an old stable version which hasn't been noticed for a long
time and which in unlikely to get fixed could be downgraded from
Priority-Critical by one of the programmers.
"


This means that the "regression since the last two stable
versions" becomes an ad-hoc programmer decision, rather than an
official policy decision.  Couldn't we keep the "for example,
while developing 2.13, any regression since 2.12.x or 2.10.x
counts as a critical issue" sentence?  I think that one sentence
with exact numbers would provide much more clarity than terms like
"this version" or "previous two stable versions".


On December 30 you said:
"In particular,
I'd fine telling / expecting bug squad members to make something
Critical if it's a regression, period.  Just as long as a
programmer can come by and say "wait, we broke that back in
2005... sure, it's still a bug, but we're not going to delay a
stable release for it.  I'm setting it to priority-medium"."

My wording reflects that?


--
Phil Holmes



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Mon, Jan 03, 2011 at 03:15:22AM +, Graham Percival wrote:
> On Sun, Jan 02, 2011 at 04:37:35PM -, Phil Holmes wrote:
> > "
> > Priority-Critical: LilyPond segfaults, a regression (see below)
> > against a previous stable version or a regression against a fix
> > developed for this version. This does not apply where the
> > "regression" occurred because a feature was removed deliberately -
> > this is not a bug.
> > "
> 
> I'm not certain what "regression against a fix developed for this
> version" means.

Addendum: remember that any breakage in the regression tests is a
Critical issue.  So if this was an important fix or new feature,
then the programmer should have added a regtest, and any breakage
in that regtest would be a critical bug regardless of any text
like "regression against a fix developed for this version".

It's probably worth adding something about regtest breakage to the
policy.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Sun, Jan 02, 2011 at 04:37:35PM -, Phil Holmes wrote:
> "
> Priority-Critical: LilyPond segfaults, a regression (see below)
> against a previous stable version or a regression against a fix
> developed for this version. This does not apply where the
> "regression" occurred because a feature was removed deliberately -
> this is not a bug.
> "

I'm not certain what "regression against a fix developed for this
version" means.  If somebody fixes a minor bug in 2.13.15, and
that fix doesn't work in 2.13.17, I don't think that should be a
Critical bug.  If the fix works in 2.14.0 but doesn't work in
2.14.2 or 2.15.2, then I _would_ consider that a critical bug,
under the usual "regression against the past two stable versions"
rule.

> At the bottom of this section, add:
> "
> Note that these are initial classifications and can be subject to
> change by others in the development team.  For example, a regression
> against an old stable version which hasn't been noticed for a long
> time and which in unlikely to get fixed could be downgraded from
> Priority-Critical by one of the programmers.
> "

This means that the "regression since the last two stable
versions" becomes an ad-hoc programmer decision, rather than an
official policy decision.  Couldn't we keep the "for example,
while developing 2.13, any regression since 2.12.x or 2.10.x
counts as a critical issue" sentence?  I think that one sentence
with exact numbers would provide much more clarity than terms like
"this version" or "previous two stable versions".


I don't mind if you want to hide the precise-version-number
example sentence somewhere where normal bug squad members won't
find it, but I think it should be in that chapter somewhere.

> In "Other items"
> 
> "
> Regression: it used to work intentionally in an earlier stable
> release. If the earlier output was accidental (i.e. we didn't try to
> stop a collision, but it just so happened that two grobs didn't
> collide), then changing the output does not count as a regression.
> 
> To help decide whether the change is a regression, and therefore
> should be Priority-Critical, please adopt the following process:
> 
> 1. Are you certain the change is OK?  If so, do nothing.
> 2. Are you certain that the change is bad?  Add it to the tracker as
> a Critical issue, regression.
> 3. If you're not certain either way, add it to the tracker as a
> Critical issue, regression but be aware that it may be recategorised
> or marked invalid.
> "

This is fine.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Phil Holmes]

[snip long-ish discussion]

OK, I think we reached a conclusion on this and so would like to make a 
patch.  I propose:


"
Priority-Critical: LilyPond segfaults, a regression (see below) against a 
previous stable version or a regression against a fix developed for this 
version. This does not apply where the "regression" occurred because a 
feature was removed deliberately - this is not a bug.

"

At the bottom of this section, add:
"
Note that these are initial classifications and can be subject to change by 
others in the development team.  For example, a regression against an old 
stable version which hasn't been noticed for a long time and which in 
unlikely to get fixed could be downgraded from Priority-Critical by one of 
the programmers.

"

In "Other items"

"
Regression: it used to work intentionally in an earlier stable release. If 
the earlier output was accidental (i.e. we didn't try to stop a collision, 
but it just so happened that two grobs didn't collide), then changing the 
output does not count as a regression.


To help decide whether the change is a regression, and therefore should be 
Priority-Critical, please adopt the following process:


1. Are you certain the change is OK?  If so, do nothing.
2. Are you certain that the change is bad?  Add it to the tracker as a 
Critical issue, regression.
3. If you're not certain either way, add it to the tracker as a Critical 
issue, regression but be aware that it may be recategorised or marked 
invalid.

"

--
Phil Holmes 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Sat, Jan 01, 2011 at 01:06:04PM +0100, Karl Hammar wrote:
> Graham:
> > Of course, writing artistic and research grants is a non-trivial
> > amount of work, and it's hardly guaranteed to have any results.
> > But I think that with the right angle -- be that "collaborative
> > folk music archival", or "high-quality, specialized music
> > notation", or "educational software for cheap 3rd-world donated
> > computers", I could imagine getting a grant.
> 
> In Uppsala there is one person at the music institution who is
> interested in Schenker analysis. Could that be a lead?

I'm not certain that it's worth approaching somebody who doesn't
already use lilypond.  Also, I don't think it's worth discussing
this on the -devel list.  If you're interested in organizing this
kind of thing, I'd recommend asking on -user.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Karl Hammar]

Graham:
> On Sat, Jan 01, 2011 at 09:10:49AM +0100, Werner LEMBERG wrote:
...
> > But maybe there is a group of LilyPond philanthropists who can afford
> > this and are willing to do so...
> I'm not optimistic about that; I think a more realistic
> opportunity would be to get some grant money from some artistic
> organization.  ...
> 
> Of course, writing artistic and research grants is a non-trivial
> amount of work, and it's hardly guaranteed to have any results.
> But I think that with the right angle -- be that "collaborative
> folk music archival", or "high-quality, specialized music
> notation", or "educational software for cheap 3rd-world donated
> computers", I could imagine getting a grant.

In Uppsala there is one person at the music institution who is
interested in Schenker analysis. Could that be a lead?

Regards,
/Karl Hammar

-
Aspö Data
Lilla Aspö 148
S-742 94 Östhammar
Sweden
+46 173 140 57



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

Graham Percival  writes:

> In my idle moments, I like to discourage myself by trying to
> figure out how long it would take to achieve something
> "reasonable" for users.  Let's play this game now, and start
> making some unrealistic-but-just-possible assumptions:
> 1. "reasonable" means 100 bugs.  Let's also assume that these can
> be the 100 most problematic bugs (i.e. we can fix the easy ones
> first without penalizing this "reasonable" goal).
> 2. with the new lilydev iso, we can gather 10 new programmers.
> Keith, Phil, Janek, etc.
> 3. each of those 10 programmers can fix an average of 1 issue
> every 10 days.  By "fix", I mean "understand the problem, read the
> code, produce patches for review, respond to comments, make new
> drafts, and have somebody push the final fix".
> 4. the existing developers are capable of doing all the reviewing
> for all these patches.
> 5. we continue to get approximately 1 new issue every 3 days.

That's developing logistics for pails in order to deal with an
unfinished roof because nobody remembers where the trapdoor to the attic
was.  The number of bugs is not the problem.  The problem is that the
skills needed to deal with the bugs and other problems are not in a
sensible relation to the complexity of the bugs.

A _sensible_ investment of time would be to move a considerable number
of engravers to Scheme.  And keep them _there_ rather than just doing it
as an example.  Presto, we get a bunch of code (_iff_ the style of
Scheme is not wallowing inscrutably in macros and idiosyncrasies like
some of the C++ code) that can be maintained with more confidence than
"poke with a stick and see what happens".

Then the roof at least leaks in accessible places.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[David Kastrup]

"Keith OHara"  writes:

> On Fri, 31 Dec 2010 16:31:23 -0800, Trevor Daniels
>  wrote:
>> ... the concern I had was this.  Quite a lot of the
>> documentation was written, not by inspecting the code
>> to see what was intended, but by experimenting and
>> writing up what was found.  I certainly worked that
>> way, and I think Mark and Keith did recently in
>> documenting the new spacing stuff.
>
> Pretty much.  If it makes you feel better, I did read a fair bit of
> the code to help build up a mental model of how things worked.

The problem is that one is documenting the implementation, not the
designed interface.  Which is fixating things at the wrong end of the
stick: the implementation should be free to gravitate towards its best
state without having to change the documentation and/or the interface.

-- 
David Kastrup


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Sat, Jan 01, 2011 at 09:39:37AM +0100, Werner LEMBERG wrote:
> 
> > I'm not optimistic about that; I think a more realistic opportunity
> > would be to get some grant money from some artistic organization.
> 
> Mhmm.  `Programming' in its broadest sense is research, thus getting
> grants limits the number of persons enormously.  However, the number
> of music researchers (this is, persons who work in the academical
> field and who can actually apply for a grant) who can program is very
> limited, I believe.  And normally, grants are always too limited to be
> shared with external resources...

?  Hiring outside talent is not unusual for Canadian and UK
research grants.  A music professor using part of a grant to hire
a programmer (generally to do the "technical side" of an
electroacoustic composition), or an engineering professor using
part of a grant to hire professional musicians to perform
something (which he will then analyze), is entirely normal.

I readily acknowledge that writing grant applications is a very
specific skill -- each granting agency wants to see something
slightly different in its applications; a perfect application for
one agency might be a terrible application for another one.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Jan Warchoł]

2011/1/1 Werner LEMBERG :
> What we would need is a payed full-time developer.  However, this is
> expensive.  Assuming that the programmer has a family with children,
> an appartment, etc., and to provide a reasonably good living for him
> or her, this would be about 3000 Euros a month here in Austria or
> Germany (one third of the amount would immediately vanish as taxes and
> social security payments).
>
> But maybe there is a group of LilyPond philanthropists who can afford
> this and are willing to do so...

I'd gladly help with that, however my input would be limited :( Let's
say 15 euro/month.
Now let's find another 200 people like me :-|

yours Pondly,
Janek

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Trevor Daniels]

Graham Percival wrote Saturday, January 01, 2011 7:16 AM



Nope, for precisely the reason you gave earlier: our documentation
generally has zero input from programmers, so it's not at all a
good representation of "what's intended".

We have a set of "intended to be working" examples.  They're
called the regression tests.  No more, no less.  If a patch breaks
those, then we reject the patch.  If we notice in time.

Look, we simply *cannot* offer users anything that would be
"reasonable" by most standards.


[snip persuasive argument]

You're right (as usual :)  In our circumstances we must
be pragmatic.


I think our best bet is:
1. stabilize and release 2.14, using the most restrictive
interpretation of "stabilize" and "critical issue" we can.
2. drastically reduce (or abandon entirely) development for 3
months while we sort out the GOP policy questions (many of which
should ease future development)
3. start picking up the pieces and try to recruit more
contributors.


OK, I can go along with this.

Trevor



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Werner LEMBERG]

> I'm not optimistic about that; I think a more realistic opportunity
> would be to get some grant money from some artistic organization.

Mhmm.  `Programming' in its broadest sense is research, thus getting
grants limits the number of persons enormously.  However, the number
of music researchers (this is, persons who work in the academical
field and who can actually apply for a grant) who can program is very
limited, I believe.  And normally, grants are always too limited to be
shared with external resources...

In particular, grants are not applicable by persons like me who are
musicians and not music researchers.


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Sat, Jan 01, 2011 at 09:10:49AM +0100, Werner LEMBERG wrote:
> What we would need is a payed full-time developer.

That could help.  Or at least having a sponsorship page up, which
brings us back to the GOP policy list and the current decision not
to begin discussing those until we've gotten 2.14 out the door.

> But maybe there is a group of LilyPond philanthropists who can afford
> this and are willing to do so...

I'm not optimistic about that; I think a more realistic
opportunity would be to get some grant money from some artistic
organization.  Either a music-composition grant (of which a
composer might dedicate x% towards lilypond sponsorship), or an
art history / research grant.  I think the latter is more
likely... for example, if somebody got a grant to typeset 17th
century Norweigan folk songs, and decided to use lilypond, and
spent x% of the grant towards "improving community-oriented tools
for folk music archival", etc.

Of course, writing artistic and research grants is a non-trivial
amount of work, and it's hardly guaranteed to have any results.
But I think that with the right angle -- be that "collaborative
folk music archival", or "high-quality, specialized music
notation", or "educational software for cheap 3rd-world donated
computers", I could imagine getting a grant.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Werner LEMBERG]

> What we would need is a payed full-time developer.

I have forgotten to say that such a developer needs certain skills in
addition to C++ and Scheme, namely being a musician...


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Werner LEMBERG]

> Look, we simply *cannot* offer users anything that would be
> "reasonable" by most standards.  We have "highly embarrassing" bugs
> from 2006 that we're not even *pretending* to be working on.  We've
> been in "release crunch" mode for at least six months.  The only
> glimmer of hope on the horizon is that, under the most strict
> interpretation of "critical regression", almost none of those bugs
> were introduced recently.  So there's a chance that once we "catch
> up" on the old critical regressions, we won't have many new ones,
> and thus we can move forward with a stable foundation.

What we would need is a payed full-time developer.  However, this is
expensive.  Assuming that the programmer has a family with children,
an appartment, etc., and to provide a reasonably good living for him
or her, this would be about 3000 Euros a month here in Austria or
Germany (one third of the amount would immediately vanish as taxes and
social security payments).

But maybe there is a group of LilyPond philanthropists who can afford
this and are willing to do so...


Werner

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Sat, Jan 01, 2011 at 12:31:23AM -, Trevor Daniels wrote:
> 
> Graham Percival wrote Friday, December 31, 2010 11:20 PM
> 
> >However, lilypond never intentionally tried to
> >avoid those objects colliding -- in fact, intentionally avoiding
> >this collision would require a fair chunk of extra code.  Should
> >we hold back a stable release just for this?
> 
> Well, I don't intend to die in the ditch over this,
> but the concern I had was this.  Quite a lot of the
> documentation was written, not by inspecting the code
> to see what was intended, but by experimenting and
> writing up what was found.

Yep.

> I certainly worked that
> way, and I think Mark and Keith did recently in
> documenting the new spacing stuff.  In doing that we
> had no idea whether the things we find are intentional
> or a happy coincidence of bugs.

Welcome to lilypond development.  :(

> Now if you can work
> in something about "working as intended or documented"
> wrt determining critical bugs

Nope, for precisely the reason you gave earlier: our documentation
generally has zero input from programmers, so it's not at all a
good representation of "what's intended".

We have a set of "intended to be working" examples.  They're
called the regression tests.  No more, no less.  If a patch breaks
those, then we reject the patch.  If we notice in time.


...

Look, we simply *cannot* offer users anything that would be
"reasonable" by most standards.  We have "highly embarrassing"
bugs from 2006 that we're not even *pretending* to be working on.
We've been in "release crunch" mode for at least six months.  The
only glimmer of hope on the horizon is that, under the most strict
interpretation of "critical regression", almost none of those bugs
were introduced recently.  So there's a chance that once we "catch
up" on the old critical regressions, we won't have many new ones,
and thus we can move forward with a stable foundation.

As a long-time observer and developer, the only honest thing we
can offer users is this:
1. lilypond is distributed without warrantee, including the
implied warantee of fitness for a particular purpose.
(paraphrased from the license)
2. if you find a bug, and make a perfect bug report, then there's
a 90% chance that no programmer will ever look at it.  That chance
increases if you make an imperfect bug report.
3. if you want stability, then never upgrade your lilypond
version.

In my idle moments, I like to discourage myself by trying to
figure out how long it would take to achieve something
"reasonable" for users.  Let's play this game now, and start
making some unrealistic-but-just-possible assumptions:
1. "reasonable" means 100 bugs.  Let's also assume that these can
be the 100 most problematic bugs (i.e. we can fix the easy ones
first without penalizing this "reasonable" goal).
2. with the new lilydev iso, we can gather 10 new programmers.
Keith, Phil, Janek, etc.
3. each of those 10 programmers can fix an average of 1 issue
every 10 days.  By "fix", I mean "understand the problem, read the
code, produce patches for review, respond to comments, make new
drafts, and have somebody push the final fix".
4. the existing developers are capable of doing all the reviewing
for all these patches.
5. we continue to get approximately 1 new issue every 3 days.

I think the above assumptions are unrealistic, but just about
possible.  How long will it take us to reach 100 issues?

Well, we fix 356 issues a year (10 issues per 10 days); let's call
that 350 to make it even.  We add 100 issues a year (1/3*356).  So
our "bug debt" reduces by 250 a year.  We currently have 528
issues, so it'll take us slightly less than 2 years to fix the
easiest 80% of bugs.  Given all those unrealistic assumptions.

Really, things are going to get worse before they get better.  I
fully expect to hit 800 open issues before we manage to start
fixing more issues than we add.

I think our best bet is:
1. stabilize and release 2.14, using the most restrictive
interpretation of "stabilize" and "critical issue" we can.
2. drastically reduce (or abandon entirely) development for 3
months while we sort out the GOP policy questions (many of which
should ease future development)
3. start picking up the pieces and try to recruit more
contributors.

We might achieve "issue count balance" by mid-2011, and if we're
*really* lucky (and/or work hard), we might be able to reduce the
open issue count to less than 500 (and keep it there!) by the end
of 2011.  I know that sounds like a really modest goal, but at the
moment I'm not even optimistic about reaching /that/ target.

- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Keith OHara]

On Fri, 31 Dec 2010 16:31:23 -0800, Trevor Daniels  
wrote:

... the concern I had was this.  Quite a lot of the
documentation was written, not by inspecting the code
to see what was intended, but by experimenting and
writing up what was found.  I certainly worked that
way, and I think Mark and Keith did recently in
documenting the new spacing stuff.


Pretty much.  If it makes you feel better, I did read a fair bit of the code to 
help build up a mental model of how things worked.  You remember that we 
rejected documenting those cross-staff collisions, until the code made it clear 
to me that some collisions were intentional, and possibly unavoidable.  More 
generally, we naturally sort our experimental findings into possible-bugs and 
oh-that's-how-it-works-s


Now if you can work
in something about "working as intended or documented"


That sounds good, and natural.
In most people's minds, documented implies intended.


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Trevor Daniels]

Graham Percival wrote Friday, December 31, 2010 11:20 PM



On Thu, Dec 30, 2010 at 08:43:36PM +, Keith OHara wrote:

Trevor Daniels  treda.co.uk> writes:
> Graham Percival wrote Thursday, December 30, 2010 3:56 AM
> >
> > I want to keep the word "intentionally", though -- if 
> > something
> > only happened to work because of a happy coincidence of bugs, 
> > then

> > "breaking" that should not be a Critical bug.
>
> I'm not sure about this.  The purpose of selecting
> out bugs to be critical is to ensure the user who
> keeps up to date with the stable series of releases
> can be sure nothing in the new release is going to
> break his scores.  He doesn't care whether something
> worked just by a happy coincidence of bugs. [...]


Suppose we have a pair of memory leaks.  One leak writes junk to
memory as part of the guile initalization, and another leak reads
junk from memory as part of the spacing algorithm.  This pair of
bugs happens to result in a pair of objects not colliding.  When
we fix one of these bugs, the objects happen to collide.  Oh no,
it's a regression!  However, lilypond never intentionally tried to
avoid those objects colliding -- in fact, intentionally avoiding
this collision would require a fair chunk of extra code.  Should
we hold back a stable release just for this?


Well, I don't intend to die in the ditch over this,
but the concern I had was this.  Quite a lot of the
documentation was written, not by inspecting the code
to see what was intended, but by experimenting and
writing up what was found.  I certainly worked that
way, and I think Mark and Keith did recently in
documenting the new spacing stuff.  In doing that we
had no idea whether the things we find are intentional
or a happy coincidence of bugs.  Now if you can work
in something about "working as intended or documented"
wrt determining critical bugs I'd be happier.

Also, without the filter of intentionality, you end up arguing 
about whether the

feature is important, which is much more subjective.


Yes.


It is, but it might be relevant if fixing a minor
bug exposed a more serious one.

Trevor



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Thu, Dec 30, 2010 at 08:43:36PM +, Keith OHara wrote:
> Trevor Daniels  treda.co.uk> writes:
> > Graham Percival wrote Thursday, December 30, 2010 3:56 AM
> > >
> > > I want to keep the word "intentionally", though -- if something
> > > only happened to work because of a happy coincidence of bugs, then
> > > "breaking" that should not be a Critical bug.
> > 
> > I'm not sure about this.  The purpose of selecting
> > out bugs to be critical is to ensure the user who
> > keeps up to date with the stable series of releases
> > can be sure nothing in the new release is going to
> > break his scores.  He doesn't care whether something
> > worked just by a happy coincidence of bugs. [...]

Suppose we have a pair of memory leaks.  One leak writes junk to
memory as part of the guile initalization, and another leak reads
junk from memory as part of the spacing algorithm.  This pair of
bugs happens to result in a pair of objects not colliding.  When
we fix one of these bugs, the objects happen to collide.  Oh no,
it's a regression!  However, lilypond never intentionally tried to
avoid those objects colliding -- in fact, intentionally avoiding
this collision would require a fair chunk of extra code.  Should
we hold back a stable release just for this?

This isn't a theoretical example.  I can't remember if the cause
was a pair of memory leaks, but we *have* introduced collision
"bugs" due to general spacing improvements, where the lack of
collisions was never intentional.

> Also, without the filter of intentionality, you end up arguing about whether 
> the 
> feature is important, which is much more subjective.

Yes.

I'm not saying that the new behaviour wouldn't be a bug; just that
this bug should not delay a new stable release.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Keith OHara]

Trevor Daniels  treda.co.uk> writes:
> Graham Percival wrote Thursday, December 30, 2010 3:56 AM
> >
> > I want to keep the word "intentionally", though -- if something
> > only happened to work because of a happy coincidence of bugs, then
> > "breaking" that should not be a Critical bug.
> 
> I'm not sure about this.  The purpose of selecting
> out bugs to be critical is to ensure the user who
> keeps up to date with the stable series of releases
> can be sure nothing in the new release is going to
> break his scores.  He doesn't care whether something
> worked just by a happy coincidence of bugs. [...]

Products in general allow unintentional features to disappear in new versions.  
Features that were intentional, but unwise, often get a deprecated label for
one cycle.  I think this is practically necessary to allow the system or 
software to move forward.

Also, without the filter of intentionality, you end up arguing about whether 
the 
feature is important, which is much more subjective.

I recommend keeping intentionality, at least as a distinction between must-fix 
bugs and must-note-in-Changes.

My piano scores will break in 2.14 because I used the auto-beaming in cadenzas
--or they would if not for my adjusting them in response to the item in Changes.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Trevor Daniels]

Graham Percival wrote Thursday, December 30, 2010 3:56 AM

On Wed, Dec 29, 2010 at 12:32:56PM -, Phil Holmes wrote:

From: "Carl Sorensen" 
>On 12/28/10 4:18 PM, "Graham Percival" 
> wrote:

>
>The difference between Phil's version and the previous version 
>is

>
>"Something that worked as it should in a previous version, and 
>now doesn't

>work." vs.
>
>"Something that worked intentionally in one of the previous two 
>stable

>versions, and now doesn't work."


I want to keep the word "intentionally", though -- if something
only happened to work because of a happy coincidence of bugs, then
"breaking" that should not be a Critical bug.


I'm not sure about this.  The purpose of selecting
out bugs to be critical is to ensure the user who
keeps up to date with the stable series of releases
can be sure nothing in the new release is going to
break his scores.  He doesn't care whether something
worked just by a happy coincidence of bugs.  All he
will see is a new stable release that breaks his scores.

Shouldn't we avoid doing that?

Trevor



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Wed, Dec 29, 2010 at 12:32:56PM -, Phil Holmes wrote:
> From: "Carl Sorensen" 
> >On 12/28/10 4:18 PM, "Graham Percival"  wrote:
> >
> >The difference between Phil's version and the previous version is
> >
> >"Something that worked as it should in a previous version, and now doesn't
> >work." vs.
> >
> >"Something that worked intentionally in one of the previous two stable
> >versions, and now doesn't work."
> 
> That's about it.

I want to keep the word "intentionally", though -- if something
only happened to work because of a happy coincidence of bugs, then
"breaking" that should not be a Critical bug.

>  Graham wants a regression from (say) 2.6 not to
> count as critical.  I thought this was somewhat confusing to new
> bug-squadders to understand and wanted all regressions to count the
> same.

There's two questions here:
1. what do we want to teach new bug squad members / what do we
want bug squad members to do?  (IMO these should be the same
thing)
2. what should be the actual priority of a particular issue.

The answer to these need not be the same thing.  In particular,
I'd fine telling / expecting bug squad members to make something
Critical if it's a regression, period.  Just as long as a
programmer can come by and say "wait, we broke that back in
2005... sure, it's still a bug, but we're not going to delay a
stable release for it.  I'm setting it to priority-medium".


Remember the goal of the bug squad is to handle routine
administrative tasks so that programmers can concentrate on more
advanced tasks.  If a non-routine task is causing confusion to bug
squad members, or if the administration is causing a burden on
programmers, then it's time to reconsider stuff.


> IMO the question is likely to be moot anyway, since I think
> it's quite unlikely we'll see such a regression reported.

Based on past experience, I'd say there's a >50% chance of seeing
at least two reports of such regressions over the next year.

> >>>  TBH I was uncertain whether to add this to the tracker
> >>> at all and only did so because I had a few attempts at getting views
> >>> on whether it was a problem, with no response.  I probably labelled
> >>> it a regression, but possibly wrongly.
> >>
> >> My thought process would be this:
> >> 1. am I certain that the new position is ok?  If so, do nothing.
> >> 2. am I certain that the new position is not ok?  If so, add it as
> >> a Critical issue with a brief description of the problem.
> >> 3. am I not certain either way?  If so, add it as a Critical
> >> issue, but note that it may or may not be an actual problem.
> 
> 
> I'd like to add this guidance to the CG, too.

Sure, sounds fine.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Reinhold Kainhofer]

Am Mittwoch, 29. Dezember 2010, um 04:57:47 schrieb Carl Sorensen:
> On 12/28/10 4:18 PM, "Graham Percival"  wrote:
> > In the case of #3, if it's not actually a problem, then when a
> > programmer takes a look at the issue, they can quickly mark it as
> > an "invalid" report.  I agree that it would be nice if we could
> > find out about such invalid reports sooner (ideally before adding
> > it at all!), but the evidence is that we cannot rely on people
> > replying all the time.
> 
> Reinhold is the current FiguredBass guru.  Have we tried asking him if this
> output is acceptable?

Yes, see my message on December 7:
http://lists.gnu.org/archive/html/lilypond-devel/2010-12/msg00146.html

Well, that's because the markup and the "0" (used for the hidden figure) have 
different vertical alignment points (center for the cirdle, baseline for all 
numbers). It's not ideal, but I have never seen a markup (without figures) in 
figured bass, so I don't think it's a big deal. One can always play around with 
alignment points to get the markup to the correct position.

So, in other words, while it might not be correct/ideal behavior, I don't 
think it has any real world implications.

Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://reinhold.kainhofer.com/
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * LilyPond, Music typesetting, http://www.lilypond.org

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Carl Sorensen]

On 12/28/10 4:18 PM, "Graham Percival"  wrote:

> On Tue, Dec 28, 2010 at 01:24:32PM -, Phil Holmes wrote:
>> - Original Message - From: "Graham Percival"
>> 
>> I think one of these was mine.  This is the thing I want to discuss
>> before creating a patch.  I think the real problem over the
>> definitions is what counts as a "regression".  My definition would
>> be "something that worked as it should in a previous version, and
>> now doesn't work".
> 
> At first glance, that seems to be right.

The difference between Phil's version and the previous version is

"Something that worked as it should in a previous version, and now doesn't
work." vs.

"Something that worked intentionally in one of the previous two stable
versions, and now doesn't work."

>>  TBH I was uncertain whether to add this to the tracker
>> at all and only did so because I had a few attempts at getting views
>> on whether it was a problem, with no response.  I probably labelled
>> it a regression, but possibly wrongly.
> 
> My thought process would be this:
> 1. am I certain that the new position is ok?  If so, do nothing.
> 2. am I certain that the new position is not ok?  If so, add it as
> a Critical issue with a brief description of the problem.
> 3. am I not certain either way?  If so, add it as a Critical
> issue, but note that it may or may not be an actual problem.
> 
> In the case of #3, if it's not actually a problem, then when a
> programmer takes a look at the issue, they can quickly mark it as
> an "invalid" report.  I agree that it would be nice if we could
> find out about such invalid reports sooner (ideally before adding
> it at all!), but the evidence is that we cannot rely on people
> replying all the time.

Reinhold is the current FiguredBass guru.  Have we tried asking him if this
output is acceptable?

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: critical issues

[Graham Percival]

On Tue, Dec 28, 2010 at 01:24:32PM -, Phil Holmes wrote:
> - Original Message - From: "Graham Percival"
> >Ironically, although the current printed policy seems to be too
> >inclusive for Critical issues, my main concern is that bug squad
> >members are classifying stuff as High instead of Critical.  It's
> >going to be a real downer if we suddenly discover half a dozen
> >Crittical regressions which were "hiding" as High issues after the
> >first release candidate.
> 
> I think one of these was mine.  This is the thing I want to discuss
> before creating a patch.  I think the real problem over the
> definitions is what counts as a "regression".  My definition would
> be "something that worked as it should in a previous version, and
> now doesn't work".

At first glance, that seems to be right.

> If we look at 1438, it would fail that
> definition - it's a change, sure, but the marking has moved, not
> disappeared.

Is the new position of the marking "working" ?  Some markings can
be moved by some amount without making it "not work".

>  TBH I was uncertain whether to add this to the tracker
> at all and only did so because I had a few attempts at getting views
> on whether it was a problem, with no response.  I probably labelled
> it a regression, but possibly wrongly.

My thought process would be this:
1. am I certain that the new position is ok?  If so, do nothing.
2. am I certain that the new position is not ok?  If so, add it as
a Critical issue with a brief description of the problem.
3. am I not certain either way?  If so, add it as a Critical
issue, but note that it may or may not be an actual problem.

In the case of #3, if it's not actually a problem, then when a
programmer takes a look at the issue, they can quickly mark it as
an "invalid" report.  I agree that it would be nice if we could
find out about such invalid reports sooner (ideally before adding
it at all!), but the evidence is that we cannot rely on people
replying all the time.


However, priority-High is absolutely *not* a substitute for "it
might be critical, it might be, I'm not certain".  Virtually
nobody will look at it, so we'll be stuck with a "maybe a problem,
maybe not" issue for the next few years.

Cheers,
- Graham

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 881 Arpeggios may collide with laissezVibrer ties (was Re: Critical issues)

[Karl Hammar]

And here comes the test-baseline file.

Regards,
/Karl Hammar
<>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 881 Arpeggios may collide with laissezVibrer ties (was Re: Critical issues)

[Karl Hammar]

-
This is a multipart MIME message.
Karl Hammar:
> Carl Sorensen:
> ...
> > I've posted a patch on Rietveld.  Can you do the
> > regression test?
> > http://codereview.appspot.com/1195044
> 
> After a make test-redo I get:
> 
> . the "mandatory" output-distance.
> . a diff of tree.gittext, showing Carls patch
> . 314 below threshold
> . 2062 unchanged
> 
> From this I assume Carls patch does not affect any present regression
> test.

Sorry to bring this up again, but this conclusion is still unproven,
since the test was done with "test-redo". As I have found out in the 
thread for the issue 915, "test-redo" does not test the things we
wanted to test.

***



$ git-status 
# On branch master
# Untracked files:
#   (use "git add ..." to include in what will be committed)
#
#   issue1195044_1_2.diff
#   issue1195044_1_3.diff
#   issue931041_1.diff
nothing added to commit but untracked files present (use "git add" to track)
$ git-log | head -1
commit 22d889f4d27469864c31db81445e9de49774ae23
$ cat issue1195044_1_[23].diff | patch -p1  
patching file scm/define-grobs.scm
patching file scm/output-lib.scm
$ make check > log 2>&1
...

And I get a distance of 18.406667 in the attached output. The
difference seems to be because the c and the b are horizontally closer 
to each other.

Regards,
/Karl Hammar

<><>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 881 Arpeggios may collide with laissezVibrer ties (was Re: Critical issues)

[Carl Sorensen]

On 5/15/10 1:12 AM, "Karl Hammar"  wrote:

> Carl Sorensen:
> ...
>> I've posted a patch on Rietveld.  Can you do the
>> regression test?
>> http://codereview.appspot.com/1195044
> 
> After a make test-redo I get:
> 
> . the "mandatory" output-distance.
> . a diff of tree.gittext, showing Carls patch
> . 314 below threshold
> . 2062 unchanged
> 
> From this I assume Carls patch does not affect any present regression
> test.

Yes, this is correct.  Thanks for doing that!

> 
> ***
> 
> But I also notice that there are no test for the present problem.
> Perhaps one should be added?

Yes, it should.  I forgot to do that.  The one present in the report would
be the proper one to use.  Thanks for the catch!

> ***
> 
> I also note that input/regression/laissez-vibrer-ties.ly has a bar
> check failure:
> 
> \relative c' {
>   \laissezVibrer r4
>   \laissezVibrer r
>   \laissezVibrer r
>   4.\laissezVibrer r % here we get a bar check failure
> 
> In Documentation/snippets/laissez-vibrer-ties.ly we have a r8 at that
> point, otherwise thoose two are basically the same.
> 
> What was the point of having a bar check failure in the regression
> test?

I suspect nothing -- it's just an error.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 881 Arpeggios may collide with laissezVibrer ties (was Re: Critical issues)

[Karl Hammar]

Carl Sorensen:
...
> I've posted a patch on Rietveld.  Can you do the
> regression test?
> http://codereview.appspot.com/1195044

After a make test-redo I get:

. the "mandatory" output-distance.
. a diff of tree.gittext, showing Carls patch
. 314 below threshold
. 2062 unchanged

>From this I assume Carls patch does not affect any present regression
test.

***

But I also notice that there are no test for the present problem.
Perhaps one should be added?

The one presented in the report[1] could be a candidate, comments?

\version "2.12.1" % regression: 2.10.33 and 2.8.8 are ok

{
 \laissezVibrer  \arpeggio
 \laissezVibrer  \arpeggio \mark "never"
 \laissezVibrer  \arpeggio
 \laissezVibrer  \arpeggio
 \bar "||"
 \laissezVibrer  \arpeggio
 \laissezVibrer  \arpeggio \mark "sometimes"
 \laissezVibrer  \arpeggio
 \laissezVibrer  \arpeggio
 \bar "||"
 \laissezVibrer  \arpeggio
 \laissezVibrer  \arpeggio \mark "always"
 \laissezVibrer  \arpeggio
 \laissezVibrer  \arpeggio
}

***

I also note that input/regression/laissez-vibrer-ties.ly has a bar 
check failure:

\relative c' {
  \laissezVibrer r4
  \laissezVibrer r
  \laissezVibrer r
  4.\laissezVibrer r % here we get a bar check failure

In Documentation/snippets/laissez-vibrer-ties.ly we have a r8 at that 
point, otherwise thoose two are basically the same.

What was the point of having a bar check failure in the regression 
test?

Regards,
/Karl Hammar

[1] http://code.google.com/p/lilypond/issues/detail?id=881



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Issue 881 Arpeggios may collide with laissezVibrer ties (was Re: Critical issues)

[Carl Sorensen]

On 5/14/10 8:18 AM, "Karl Hammar"  wrote:

> Carl Sorensen:
>> On 5/14/10 7:01 AM, "Karl Hammar"  wrote:
>>> Carl Sorensen:
> ...
>> You also need to redefine the 'stencil for laissez-vibrez tie in
>> scm/define-grobs.scm.
> ...
> 
> I can help with doning the regression test. Second-guessing what
> Niels patch was about was not included in that offer.
> 

Thanks for your offer.  I've posted a patch on Rietveld.  Can you do the
regression test?

Thanks,

Carl

http://codereview.appspot.com/1195044


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Issue 881 Arpeggios may collide with laissezVibrer ties (was Re: Critical issues)

[Karl Hammar]

Carl Sorensen:
> On 5/14/10 7:01 AM, "Karl Hammar"  wrote:
> > Carl Sorensen:
...
> You also need to redefine the 'stencil for laissez-vibrez tie in
> scm/define-grobs.scm.
...

I can help with doning the regression test. Second-guessing what 
Niels patch was about was not included in that offer.

Regards,
/Karl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Critical issues

[Carl Sorensen]

On 5/14/10 7:01 AM, "Karl Hammar"  wrote:

> Carl Sorensen:
>> On 5/13/10 1:11 PM, "Karl Hammar"  wrote:
> ...
>> make test-baseline
> ...
>> make check
> ...
> 
> Ok, done that.
> 
> With the guidance from http://code.google.com/p/lilypond/issues/detail?id=881:
> 
>   I can't explain why, but making the print function pure by redefining
> ly:tie::print
>   just for LaissezVibrerTie seems to fix this (I haven't done a regtest check,
> so it
>   might end up breaking something else):
> 
>   (define-public (laissez-vibrer::print grob)
> (ly:tie::print grob))
> 
>   (then add laissez-vibrer::print to pure-print-callbacks)
> 
> I tried this:
> 
>   diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm
>   index 176debd..35186f8 100644
>   --- a/scm/define-grobs.scm
>   +++ b/scm/define-grobs.scm
>   @@ -2345,8 +2345,12 @@
> (interval-union '(0 . 0) (cons smaller larger)))
>   '(0 . 0
> 
>   +(define-public (laissez-vibrer::print grob)
>   +  (ly:tie::print grob))
>   +
>(define pure-print-callbacks
>  (list
>   +   laissez-vibrer::print
>   fret-board::calc-stencil
>   note-head::brew-ez-stencil
>   print-circled-text-callback
> 
> $ make test-redo
> 
>> out/test-results/index.html
>> 
>> that shows the results of the regression tests.
> ...
> 
> I got (except the test-output-distance.ly) an distance of 0300030 and
> "HEAD is: 22d889f4d27469864c31db81445e9de49774ae23" to the right and
> left plus the git-diff to the rigth.
> 
> So I assume it was the wrong patch try. Does anybody have Neil's
> proposed fix available ?

You also need to redefine the 'stencil for laissez-vibrez tie in
scm/define-grobs.scm.

HTH,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Critical issues

[Karl Hammar]

Carl Sorensen:
> On 5/13/10 1:11 PM, "Karl Hammar"  wrote:
...
> make test-baseline
...
> make check
...

Ok, done that.

With the guidance from http://code.google.com/p/lilypond/issues/detail?id=881:

  I can't explain why, but making the print function pure by redefining 
ly:tie::print
  just for LaissezVibrerTie seems to fix this (I haven't done a regtest check, 
so it
  might end up breaking something else):

  (define-public (laissez-vibrer::print grob)
(ly:tie::print grob))

  (then add laissez-vibrer::print to pure-print-callbacks)

I tried this:

  diff --git a/scm/define-grobs.scm b/scm/define-grobs.scm
  index 176debd..35186f8 100644
  --- a/scm/define-grobs.scm
  +++ b/scm/define-grobs.scm
  @@ -2345,8 +2345,12 @@
(interval-union '(0 . 0) (cons smaller larger)))
  '(0 . 0

  +(define-public (laissez-vibrer::print grob)
  +  (ly:tie::print grob))
  +
   (define pure-print-callbacks
 (list
  +   laissez-vibrer::print
  fret-board::calc-stencil
  note-head::brew-ez-stencil
  print-circled-text-callback

$ make test-redo

> out/test-results/index.html
> 
> that shows the results of the regression tests.
...

I got (except the test-output-distance.ly) an distance of 0300030 and
"HEAD is: 22d889f4d27469864c31db81445e9de49774ae23" to the right and
left plus the git-diff to the rigth.

So I assume it was the wrong patch try. Does anybody have Neil's
proposed fix available ?

Regards,
/Karl Hammar

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Critical issues

[Marc Hohl]

Joe Neeman schrieb:

On Wed, 2010-05-12 at 22:14 +0200, Karl Hammar wrote:
  

Issue 1080: Regression: bar lines in double bar are positioned too
close together

"pnorcks" mentions commit 27a4d9354effb09c696925881ec4df007da8a0db
as a possible cause. Reverting part of that commit:
gives me the attached grace-start result which resembles the 2.13.17 
result presented in the bug tracker.


What should we do about it? 



I'd suggest we check with Marc Hohl to see what the intent of that
change was. I suspect that it was an attempt to change how \bar "||" is
aligned so that it lines up better with the new segno barline.

Yes, that's right.

 If I'm
right, though, then Marc misunderstood the last parameter to
Stencil::add_at_edge, and the correct code would be
m.add_at_edge (X_AXIS, LEFT, thin, thinkern / 2);
m.add_at_edge (X_AXIS, RIGHT, thin, thinkern);
  

Oh, I see. Yes, I misunderstood the spacing - I asked about that subject
while working on the segno patch, but no-one told me I was wrong here
(or I have missed something important).

Sorry for this, and thanks to Karl for pointing this out and to Joe for
giving the right solution. I attached a patch which does the right thing.

Thanks,

Marc

Cheers,
Joe



  


From 15b2103f19fe92c03a6f423cc93ac51e97f0a113 Mon Sep 17 00:00:00 2001
From: Marc Hohl 
Date: Fri, 14 May 2010 08:21:03 +0200
Subject: [PATCH] Issue 1080: corrected spacing in double bar lines

---
 lily/bar-line.cc |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/lily/bar-line.cc b/lily/bar-line.cc
index d3f21e5..a00dc0e 100644
--- a/lily/bar-line.cc
+++ b/lily/bar-line.cc
@@ -200,7 +200,7 @@ Bar_line::compound_barline (Grob *me, string str, Real h,
   m.add_at_edge (X_AXIS, RIGHT, thin, thinkern);
   */
   m.add_at_edge (X_AXIS, LEFT, thin, thinkern / 2);
-  m.add_at_edge (X_AXIS, RIGHT, thin, thinkern / 2);
+  m.add_at_edge (X_AXIS, RIGHT, thin, thinkern);
 }
   else if (str.find ("S") != NPOS || str == "|._.|")
 {
-- 
1.5.4.3

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Critical issues

[Carl Sorensen]

On 5/13/10 2:31 PM, "Karl Hammar"  wrote:

> Carl Sorensen:
>> On 5/13/10 2:08 PM, "Karl Hammar"  wrote:
> ...
>>> In http://code.google.com/p/lilypond/issues/detail?id=1080 there is a
>>> grace-start-good.png .
> ...
>> IIUC, Neil's patch was already demonstrated to meet issue 1.  But issue 2
>> was not yet checked.
> 
> Are you mixing this up with
> 
>   http://code.google.com/p/lilypond/issues/detail?id=881
> 

Oops!  It was another issue I was mixing it up with.  I'm sorry.

But we still need to check both issues for every patch.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Critical issues

[Karl Hammar]

Carl Sorensen:
> On 5/13/10 2:08 PM, "Karl Hammar"  wrote:
...
> > In http://code.google.com/p/lilypond/issues/detail?id=1080 there is a
> > grace-start-good.png .
...
> IIUC, Neil's patch was already demonstrated to meet issue 1.  But issue 2
> was not yet checked.

Are you mixing this up with 

  http://code.google.com/p/lilypond/issues/detail?id=881

Regards,
/Karl



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Critical issues

[Carl Sorensen]

On 5/13/10 2:08 PM, "Karl Hammar"  wrote:

> Carl Sorensen:
>> On 5/13/10 1:11 PM, "Karl Hammar"  wrote:
> ...
>>> But if I already have a known good result from the code tracker,
>>> how do I compare it with the new result?
>> 
>> What do you mean by "if I already have a known good result from the code
>> tracker"?
> 
> In http://code.google.com/p/lilypond/issues/detail?id=1080 there is a
> grace-start-good.png .
> 
>> make test-baseline
>> 
>> followed by
>> 
>> make check
> ...
> 
> I understand that I could possible go back to 2.13.17, do the make's,
> jump to current git and make test-redo.

It's not necessary to go back to 2.13.17.  All that is needed to do is to
get the current git master, build it, and run make test-baseline.

Then apply the patch, and run make check.


> 
> But if the "old good" png is already available, then I see the
> possibility to skip the "go back to..." step.

There are two separate issues:

1) Does the patch solve the problem?  This issue is tested by simply running
the sample file on the tracker to see if the output goes to the desired
state.

2) Does the patch cause any other problems?  This can only be answered by
running the complete regression test suite.

IIUC, Neil's patch was already demonstrated to meet issue 1.  But issue 2
was not yet checked.

Thanks,

Carl


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel