Carl Sorensen byu.edu> writes:
> I think a reasonable goal for 2.16 would be:
>
> 1) Work through the outstanding issues involved in issue 2070
A stable version should not wait for this. This issue removes an
obstacle to further clean-up of the input syntax, as explained
a bit more under iss
So after hearing from most of the currently-active developers, I think a
reasonable goal for 2.16 would be:
1) Work through the outstanding issues involved in issue 2070 -- Don't
wrap EventChord around all note heads. This is probably a big issue, but
I think with David working on it it will hap
2012/1/16 Carl Sorensen :
> I've been thinking more about the previous conversation about stable
> releases and coordinating work.
>
> David seemed unhappy with the idea of a stable release happening once we
> got to zero critical issues. My interpretation of his comments was that,
> while zero cr
2012/1/16 m...@apollinemike.com :
> I (like everyone I'm sure) would like to thank you for the work
> that you've done on lilypond development.
Many thanks from me, too! For your work and for your patience.
> I hope it can get farmed out amongst active developers in a way
> that makes you want t
2012/1/16 Carl Sorensen :
> I've been thinking more about the previous conversation about stable
> releases and coordinating work.
>
> David seemed unhappy with the idea of a stable release happening once we
> got to zero critical issues. My interpretation of his comments was that,
> while zero cr
David Kastrup writes:
> "m...@apollinemike.com" writes:
>
>> I think that the major deciding factor will be Guile 2.0 integration.
>
> We have had no code that has been able to survive basic testing. I
> don't think it makes sense to bank on a major feature for an _imminent_
> _stable_ release
"m...@apollinemike.com" writes:
> I think that the major deciding factor will be Guile 2.0 integration.
We have had no code that has been able to survive basic testing. I
don't think it makes sense to bank on a major feature for an _imminent_
_stable_ release when it has not even made it into a
Graham Percival writes:
> On Mon, Jan 16, 2012 at 08:07:25PM +, Carl Sorensen wrote:
>> I'm open to hearing everybody's opinion. If we can get consensus it might
>> be a powerful motivation for moving to 2.16.
>
> My position is well-known: version numbers are cheap, stable
> releases gets n
On Mon, Jan 16, 2012 at 08:07:25PM +, Carl Sorensen wrote:
> I'm open to hearing everybody's opinion. If we can get consensus it might
> be a powerful motivation for moving to 2.16.
My position is well-known: version numbers are cheap, stable
releases gets new features and bugfixes into the h
Carl Sorensen writes:
> 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? Is there
On Jan 16, 2012, at 9:07 PM, Carl Sorensen wrote:
>
> I'm open to hearing everybody's opinion. If we can get consensus it might
> be a powerful motivation for moving to 2.16.
>
> Thanks,
>
> Carl
I think that the major deciding factor will be Guile 2.0 integration. If Ian
is confident that
Reviewers: ,
Message:
Here's an attempt at fixing issue 2228, where beamlets in compound
meters don't point in the right direction.
Please review.
Description:
Fix beaming-pattern for compound meters
Please review this at http://codereview.appspot.com/5545067/
Affected files:
M lily/beamin
I've been thinking more about the previous conversation about stable
releases and coordinating work.
David seemed unhappy with the idea of a stable release happening once we
got to zero critical issues. My interpretation of his comments was that,
while zero critical issues may be a necessary cond
On Mon, Jan 16, 2012 at 04:26:04PM -, Phil Holmes wrote:
> @example
> [remote "origin"]
> fetch = +refs/heads/*:refs/remotes/origin/*
> url = ssh://git.sv.gnu.org/srv/git/lilypond.git
> @end example
This is precisely what we should avoid. Explaining how to modify
.git/config by hand is tediou
On 1/16/12 9:26 AM, "Phil Holmes" wrote:
>
>Before you start thinking about pushing a patch to staging, you
>need to ensure you have the correct local branches up to date.
>One time only, edit the .git/config file to look like this (there
>will be other lines and sections, don't touch these):
>
>
On 2012/01/16 16:16:40, Carl wrote:
Having just spent half an hour fixing up my lilygit.tcl branch, I
have personally validated the benefit of the approach now reflected
in this patch.
I will *never* again rebase a working branch to origin/staging. In
fact, I will never again have a local b
- Original Message -
From:
To: ; ;
; ;
Cc: ;
Sent: Monday, January 16, 2012 4:16 PM
Subject: Re: Issue 2100: Explanation of branches for CG (issue 5539062)
On 2012/01/16 07:54:41, Graham Percival wrote:
On Sun, Jan 15, 2012 at 11:12:49PM +,
mailto:carl.d.soren...@gmail.com wr
- Original Message -
From: "Graham Percival"
To: "Phil Holmes"
Cc: "Devel"
Sent: Monday, January 16, 2012 3:17 PM
Subject: Re: Further work on reducing make doc output - GOP 9
On Sun, Jan 15, 2012 at 02:47:23PM -, Phil Holmes wrote:
OK - so I don't think anyone has looked at th
On 2012/01/16 07:54:41, Graham Percival wrote:
On Sun, Jan 15, 2012 at 11:12:49PM +,
mailto:carl.d.soren...@gmail.com wrote:
> At this point, you have pushed dev/cg to staging without polluting
> dev/cg with staging. And you can continue to rebase dev/cg with
master
> as needed/desired.
On Mon, Jan 16, 2012 at 04:31:33PM +0100, m...@apollinemike.com wrote:
> > Instead, I will end with a plea for more automation.
>
> I have dabbled in this, mostly because I do not know what is
> needed. Python is my native language, so if people could start
> an automation wishlist, I can get thi
OK, my mistake, I didn't read the comments on top of changes.tely. The
fixed patch is attached as patch set 2.
http://codereview.appspot.com/5540058/
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypon
On Jan 16, 2012, at 1:24 PM, Graham Percival wrote:
> 2.15.26 is released, containing the fix for issue 1933
> lilypond-book on windows. This marks the end of my active
> development work for the next ten weeks: until the end of March, I
> am reducing my lilypond time from 10 hours a week to 5 ho
Graham Percival writes:
> On Sun, Jan 15, 2012 at 02:47:23PM -, Phil Holmes wrote:
>> OK - so I don't think anyone has looked at this.
>
> Quick check:
> - what does 6>&1 do? is that a named pipe?
Nope, it redirects the output on file descriptor 6 to file descriptor 1,
the standard output.
On Sun, Jan 15, 2012 at 02:47:23PM -, Phil Holmes wrote:
> OK - so I don't think anyone has looked at this.
Quick check:
- what does 6>&1 do? is that a named pipe?
- in general all the symbols looks a bit iffy... if we hadn't just
had a huge issue with python subprocess on windows, I'd sugg
New version of lilygit.tcl that:
1. Treats staging properly -- i.e. does not create a local staging
branch
2. Does rebase before pushing patch on a detached head (as now
described in cg patch)
3. Has an environment variable setting push access, so no editing of
the file is necessary (which mak
Well I'd say at the top. Many of the changes I have added in the last
year have
not necessarily gone in the correct 'order'; when someone mentioned that
something needed to be added, it went in on the top of the pile.
People do follow the changes, so the assumption is that it is current,
if we
ha
2.15.26 is released, containing the fix for issue 1933
lilypond-book on windows. This marks the end of my active
development work for the next ten weeks: until the end of March, I
am reducing my lilypond time from 10 hours a week to 5 hours a
week. In practice this means that I can reply to email
Hi Janek,
done!
Thanks
patrick
BTW: http://codereview.appspot.com/5303063/ is still open and hasn't been
pushed.
Am 16.01.2012 um 00:07 schrieb Janek Warchoł:
> Hi Patrick,
>
> your patch was pushed when i was absent; now i see that Rietveld issue
> is still opened. Could you close it please
28 matches
Mail list logo
