Re: Stable releases

>> So, with this idea in mind, I'd like to kick off a discussion about >> the next stable release. Assuming that we can fix all the critical >> issues (I think that's possible, but may be a month out or so), >> what else should we plan to have part of the next stable? Normally, a route to a stab

Re: Stable releases

On Jan 17, 2012, at 9:45 AM, Werner LEMBERG wrote: > >>> So, with this idea in mind, I'd like to kick off a discussion about >>> the next stable release. Assuming that we can fix all the critical >>> issues (I think that's possible, but may be a month out or so), >>> what else should we plan to

Re: Stable releases

>> Normally, a route to a stable release means a code freeze, applying >> only fixes to problems within the code. This also means that no >> new bug fixes get applied. Are we going to do the same? > > I don't understand the difference between the two - wouldn't a bug > be a problem within the co

Re: Stable releases

On Jan 17, 2012, at 10:01 AM, Werner LEMBERG wrote: >>> Normally, a route to a stable release means a code freeze, applying >>> only fixes to problems within the code. This also means that no >>> new bug fixes get applied. Are we going to do the same? >> >> I don't understand the difference bet

Re: Stable release proposal

2012/1/17 Carl Sorensen : > 5) Remove translations if they are not updated to 2.16.  The 2.14/2.15 > manuals can be used if desired.  Having non-updated manuals removed may > serve as an incentive to get them all translated. I partially agree but removing translations is very difficult and time co

Re: Stable release proposal

Carl, Although I'm not a current developer, I'd like to comment. In general I agree, but with the caveats below: Carl Sorensen wrote Tuesday, January 17, 2012 1:27 AM So after hearing from most of the currently-active developers, I think a reasonable goal for 2.16 would be: 1) Work through

Re: Stable release proposal

"Trevor Daniels" writes: > Carl, Although I'm not a current developer, I'd like to comment. > > In general I agree, but with the caveats below: > > Carl Sorensen wrote Tuesday, January 17, 2012 1:27 AM > > >> So after hearing from most of the currently-active developers, I think a >> reasonable g

Re: Stable release proposal

>> Normally, a route to a stable release means a code freeze, applying >> only fixes to problems within the code. This also means that no >> new bug fixes get applied. Are we going to do the same? > > I think Werner means fix only things that are not working as > advertised, but defer fixes tha

Re: Stable release proposal

2012/1/17 Carl Sorensen : > So after hearing from most of the currently-active developers, I think a > reasonable goal for 2.16 would be [...]: > > 4) Have a minimum two-week testing period with no new features -- only > bugfixes. Looks like something i can help with. I'll begin updating my lily

Broadcast articulations not in EventChord (issue 5528111)

I would advise not handling it this way - the function to_event is supposed to take music and return an event. In this patch, it is taking music, returning an event, and maybe broadcasting music and/or sending it to a context. I'd recommend creating a new iterator, rhythmic-music-iterator, that

Re: musicxml2ly: title and subtitle (issue 1913), miscellaneous (issue 5096050)

2012/1/16 pls : > BTW: http://codereview.appspot.com/5303063/ is still open and hasn't been > pushed. Oops! Looks like this patch slipped through the cracks because it wasn't mentioned in tracker issue 1985. I'm adding it now, it should be checked soon. thanks, Janek _

Re: Issue 2100: Explanation of branches for CG (issue 5539062)

Some thoughts on making all this less confusing to beginners. http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi File Documentation/contributor/source-code.itexi (right): http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-co

Re: Issue 2100: Explanation of branches for CG (issue 5539062)

On Tue, Jan 17, 2012 at 08:24:35PM +, janek.lilyp...@gmail.com wrote: > could we change this (and other similar) prefix so that it doesn't > contain a slash? I mean, change dev/ to dev- or something like that. > The slash confused me a lot, because it's also used to separate a remote > name fr

Re: Issue 2100: Explanation of branches for CG (issue 5539062)

2012/1/17 Graham Percival : >> http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode297 >> Documentation/contributor/source-code.itexi:297: git branch dev/cg >> I think it would be good to be verbose, because it will give people more >> information abou

Re: Issue 2100: Explanation of branches for CG (issue 5539062)

http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi File Documentation/contributor/source-code.itexi (right): http://codereview.appspot.com/5539062/diff/3004/Documentation/contributor/source-code.itexi#newcode297 Documentation/contributor/source-code.itexi

left-aligned notation

First of all: 1) I'm a newbie 2) I know this question seems a little bit odd... anyway: I would like to have my score (i mean the staff lines) not to be justified along the width of the page... The layout should use left-aligned notation, just as it happens with text in this few lines, in order

Re: left-aligned notation

2012/1/17 Emilio Grazzi : > First of all: 1) I'm a newbie 2) I know this question seems a little bit > odd... anyway: > I would like to have my score (i mean the staff lines) not to be justified > along the width of the page... The layout should use left-aligned notation, > just as it happens wi

Build: Strict error checking from makeinfo and texi2html (issue 2219). (issue 5554043)

Reviewers: , Description: Build: Strict error checking from makeinfo and texi2html (issue 2219). Run makeinfo and texi2html with --error-limit=0. Please review this at http://codereview.appspot.com/5554043/ Affected files: M make/doc-i18n-root-vars.make M stepmake/stepmake/texinfo-vars.mak

Re: music font

2012/1/9 Emilio Grazzi : > Hi you all, > > i'm a (typo)graphic designer from Italy and i'm about to finish my > dissertation about typography inside musical notation. > > I would like to apply my result inside lilypond like it was for the gonville > font ( http://www.chiark.greenend.org.uk/~sgtatha

Re: Glyphs for Kievan Notation (issue 4951062)

Aleksandr, i apologize for not replying so long. I've tested your patch and i see only one problem, see below. When you fix it, could you merge all changes into one commit (using 'git rebase -i origin/master'), make a patch and send it to James? I guess he has to check it manually since Patchy d

Docs: Explain the difference between ritardando and rallentando (issue 5544075)

Reviewers: , Message: The description for rallentando only said that it's an Italian word. Provide better descriptions for ritardando and rallentando, contrast them to each other and add references in both directions. Description: Docs: Explain the difference between ritardando and rallentando

changes.tely: mention Flag changes, remove duplicate "does" (issue 5540058)

Reviewers: , Message: The changelog doesn't mention the issue I have to deal with all the time, namely splitting Flag from Stem. If not that change, I would be able to use Lilypond 2.14.2 and the development version without convert-ly on the same sources. It should definitely be mentioned. An

PATCH: Countdown to 20120119

For Thursday, January 19, 2012 Critical: Issue 2100 : Patch: CG: explanation of branches for the impatient - R 5539062 Documentation: Issue 2213

Re: changes.tely: mention Flag changes, remove duplicate "does" (issue 5540058)

lgtm http://codereview.appspot.com/5540058/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Docs: Explain the difference between ritardando and rallentando (issue 5544075)

lgtm http://codereview.appspot.com/5544075/ ___ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel