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?
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
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
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
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 61 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
Graham Percival gra...@percival-music.ca 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 61 do? is that a named pipe?
Nope, it redirects the output on file descriptor 6 to file descriptor 1,
the
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 hours
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
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 things
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.
- Original Message -
From: Graham Percival gra...@percival-music.ca
To: Phil Holmes em...@philholmes.net
Cc: Devel lilypond-devel@gnu.org
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
- Original Message -
From: carl.d.soren...@gmail.com
To: gra...@percival-music.ca; k-ohara5...@oco.net;
janek.lilyp...@gmail.com; ianhuli...@gmail.com; d...@gnu.org
Cc: re...@codereview-hr.appspotmail.com; lilypond-devel@gnu.org
Sent: Monday, January 16, 2012 4:16 PM
Subject: Re: Issue
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
On 1/16/12 9:26 AM, Phil Holmes m...@philholmes.net 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
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 tedious,
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
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
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 this
Carl Sorensen c_soren...@byu.edu 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
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
Graham Percival gra...@percival-music.ca 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
m...@apollinemike.com 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
David Kastrup d...@gnu.org writes:
m...@apollinemike.com 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
2012/1/16 Carl Sorensen c_soren...@byu.edu:
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,
2012/1/16 m...@apollinemike.com 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
2012/1/16 Carl Sorensen c_soren...@byu.edu:
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,
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
Carl Sorensen c_sorensen at 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
28 matches
Mail list logo
