bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Issue 2228 in lilypond: Some users prefer to minimize partial beams


From: Graham Percival
Subject: Re: Issue 2228 in lilypond: Some users prefer to minimize partial beams rather than beam by the beat
Date: Sat, 21 Jan 2012 11:19:07 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Thu, Jan 19, 2012 at 06:10:14PM +0000, Carl Sorensen wrote:
> 
> On 1/19/12 10:05 AM, "Graham Percival" <address@hidden> wrote:
> 
> >The proper thing is to:
> >- make a branch
> >- do a local lsr update

maybe better to push right here?

> >- make your code and doc change
> >- do a local lsr update
> 
> Why is this the proper thing to do?

hmm, I have to admit that I'm no longer certain about this.

> The objective is to get the new snippet into the tree.  The way to get the
> new snippet into the tree is to add it to D/s/n and do a makelsr.py.  But
> this also updates a bunch of other files.  Why is not preferable to throw
> away all the rest of the changes, which will be redone as part of a
> release?

Err, "redone as part of a release"?  There's no makelsr.py step in
http://lilypond.org/doc/v2.15/Documentation/contributor/minor-release-checklist

I'm open to somebody adding it to the release steps, but as a
point of fact, currently the only time that makelsr.py is run is
when Phil does it once every month or two.

> Unless we are going to expect *every* user to do a local makelsr.py for
> *every* branch they create, it seems unreasonable to ask them to do it in
> advance for some branches.

I was suggesting that every contributor does a local makelsr.py
for every branch they create that modifies D/s/n/.

This would be a lot less confusing if we had regular local
makelsr.py updates.  Or if we just always did it after modifying
D/s/n/ or the D/s/n/ translations.  Or something like that.

- Graham



reply via email to

[Prev in Thread] Current Thread [Next in Thread]