On Mon, Mar 11, 2013 at 03:37:30PM +0100, David Kastrup wrote:
Colin Hall colingh...@gmail.com writes:
Absolutely. I thought that we had adopted this proposal:
http://lilypond.org/~graham/gop/gop_3.html
So what?
The policy is: David Kastrup has sole authority over what goes into
Graham Percival gra...@percival-music.ca writes:
On Mon, Mar 11, 2013 at 03:37:30PM +0100, David Kastrup wrote:
Colin Hall colingh...@gmail.com writes:
Absolutely. I thought that we had adopted this proposal:
http://lilypond.org/~graham/gop/gop_3.html
So what?
The policy is:
On 10 mars 2013, at 22:30, David Kastrup d...@gnu.org wrote:
Werner LEMBERG w...@gnu.org writes:
So, to resume, I agree that a freeze is important. When the freeze
kicks in, I'd rather that we say something like no new big projects
starting on date X will be part of 2.18 so that developers
m...@mikesolomon.org m...@mikesolomon.org writes:
On 10 mars 2013, at 22:30, David Kastrup d...@gnu.org wrote:
Werner LEMBERG w...@gnu.org writes:
So, to resume, I agree that a freeze is important. When the freeze
kicks in, I'd rather that we say something like no new big projects
On Mon, Mar 11, 2013 at 1:59 PM, David Kastrup d...@gnu.org wrote:
You see me as one person imposing a limit because I brought up the
issue of a stable release here. But I did not bring up the issue out of
spite and malice but because I realized that the kind of open-ended
changes not leading
Janek Warchoł janek.lilyp...@gmail.com writes:
On Mon, Mar 11, 2013 at 1:59 PM, David Kastrup d...@gnu.org wrote:
You see me as one person imposing a limit because I brought up the
issue of a stable release here. But I did not bring up the issue out of
spite and malice but because I realized
Janek Warchoł writes:
On Mon, Mar 11, 2013 at 1:59 PM, David Kastrup d...@gnu.org wrote:
So I see us at a crossroads here: either we decide we want to have a
stable release in a reasonable point of time in the near future, or we
decide we don't want to plan for a stable release anytime soon.
Hi,
On Mon, Mar 11, 2013 at 3:06 PM, David Kastrup d...@gnu.org wrote:
Janek Warchoł janek.lilyp...@gmail.com writes:
On Mon, Mar 11, 2013 at 1:59 PM, David Kastrup d...@gnu.org wrote:
So I see us at a crossroads here: either we decide we want to have a
stable release in a reasonable point
Colin Hall colingh...@gmail.com writes:
Janek Warchoł writes:
On Mon, Mar 11, 2013 at 1:59 PM, David Kastrup d...@gnu.org wrote:
So I see us at a crossroads here: either we decide we want to have a
stable release in a reasonable point of time in the near future, or we
decide we don't want
On Mon, Mar 11, 2013 at 3:37 PM, David Kastrup d...@gnu.org wrote:
Add some doc updates and translations if they are available, or make
them known issues if not. As Janek says, anything else goes into a
branch.
That's exactly what the disagreement is about. This anything else goes
into a
Janek Warchoł janek.lilyp...@gmail.com writes:
On Mon, Mar 11, 2013 at 3:37 PM, David Kastrup d...@gnu.org wrote:
Add some doc updates and translations if they are available, or make
them known issues if not. As Janek says, anything else goes into a
branch.
That's exactly what the
On Mon, Mar 11, 2013 at 3:53 PM, David Kastrup d...@gnu.org wrote:
Uh Janek? We have _never_ made a branch for stable releases until after
we reached a state of convergence. The problem is that in order to get
a stable release from a wobbly starting base, we need testers. If all
developers
Janek Warchoł janek.lilyp...@gmail.com writes:
On Mon, Mar 11, 2013 at 3:53 PM, David Kastrup d...@gnu.org wrote:
Uh Janek? We have _never_ made a branch for stable releases until
after we reached a state of convergence. The problem is that in
order to get a stable release from a wobbly
David Kastrup wrote Sunday, March 10, 2013 5:32 PM
2.16 is growing old.
So I want to see 2.18 soon. That means we need to stabilize work that
has already been done and cut down on experiments in the master branch.
Agreed.
Stabilizing means more or less accepting the current feature set,
Trevor Daniels t.dani...@treda.co.uk writes:
David Kastrup wrote Sunday, March 10, 2013 5:32 PM
At any rate, I'd like to aim for 2.18 at about the end of May, and
getting into serious freeze at the end of April. A focus on bug
fixes, in particular bugs introduced in the 2.17 development
On 11 mars 2013, at 16:32, Trevor Daniels t.dani...@treda.co.uk wrote:
David Kastrup wrote Sunday, March 10, 2013 5:32 PM
2.16 is growing old.
So I want to see 2.18 soon. That means we need to stabilize work that
has already been done and cut down on experiments in the master branch.
- Original Message -
From: m...@mikesolomon.org
To: Trevor Daniels t.dani...@treda.co.uk
Cc: David Kastrup d...@gnu.org; lilypond-devel@gnu.org
Sent: Monday, March 11, 2013 4:34 PM
Subject: Re: Freezing for 2.18
I like the idea of freezing right away and releasing after two weeks
m...@mikesolomon.org m...@mikesolomon.org writes:
On 11 mars 2013, at 16:32, Trevor Daniels t.dani...@treda.co.uk wrote:
I'd also like to propose we adopt the same controls as we did for
2.16, if David is willing, since that also worked well. That way
we'll get a clear plan - what must be
Phil Holmes m...@philholmes.net writes:
- Original Message -
From: m...@mikesolomon.org
To: Trevor Daniels t.dani...@treda.co.uk
Cc: David Kastrup d...@gnu.org; lilypond-devel@gnu.org
Sent: Monday, March 11, 2013 4:34 PM
Subject: Re: Freezing for 2.18
I like the idea of freezing
Hello,
On 11 March 2013 16:34, m...@mikesolomon.org m...@mikesolomon.org wrote:
On 11 mars 2013, at 16:32, Trevor Daniels t.dani...@treda.co.uk wrote:
David Kastrup wrote Sunday, March 10, 2013 5:32 PM
2.16 is growing old.
So I want to see 2.18 soon. That means we need to
James pkx1...@gmail.com writes:
On 11 March 2013 16:34, m...@mikesolomon.org m...@mikesolomon.org wrote
I like the idea of freezing right away and releasing after two
weeks of critical-bug-free lily. What is difficult for me is
setting the freeze down the line without being
Last time around, we released 2.17.0 in the _wake_ of releasing
2.16.0, and only _then_ the extensive skyline patches were placed
into 2.17 and 2.17.1 was released with them. That worked reasonably
well. We don't have the resources for parallel development and
testing, and it does not even
On Mon, Mar 11, 2013 at 7:59 PM, Werner LEMBERG w...@gnu.org wrote:
As said before, it's probably best if all developers actually use the
`stable' code since noone likes to switch between branches (due to the
enormous compilation hurdles).
You mean having to recompile each time when you switch
Ok folks, it is this time of the year again: I am trying to make myself
unpopular.
2.16 is growing old. Now you might go Huh?, but here are salient
points:
a) \override/\revert syntax is increasingly becoming an issue on the
mailing list. There are also related commands that are affected.
On 10 mars 2013, at 18:32, David Kastrup d...@gnu.org wrote:
Ok folks, it is this time of the year again: I am trying to make myself
unpopular.
There's a time of the year for that?
It also means that commits of the this really does nothing, but it
prepares the ground for $xxx, and I don't
m...@mikesolomon.org m...@mikesolomon.org writes:
On 10 mars 2013, at 18:32, David Kastrup d...@gnu.org wrote:
Ok folks, it is this time of the year again: I am trying to make
myself
unpopular.
There's a time of the year for that?
It also means that commits of the this
Am 10.03.2013 18:32, schrieb David Kastrup:
Ok folks, it is this time of the year again: I am trying to make myself
unpopular.
[...]
So I want to see 2.18 soon. That means we need to stabilize work that
has already been done and cut down on experiments in the master branch.
Stabilizing means
On 10 mars 2013, at 18:54, David Kastrup d...@gnu.org wrote:
m...@mikesolomon.org m...@mikesolomon.org writes:
On 10 mars 2013, at 18:32, David Kastrup d...@gnu.org wrote:
Ok folks, it is this time of the year again: I am trying to make
myself
unpopular.
There's a time of the
Marc Hohl m...@hohlart.de writes:
Am 10.03.2013 18:32, schrieb David Kastrup:
Ok folks, it is this time of the year again: I am trying to make myself
unpopular.
[...]
So I want to see 2.18 soon. That means we need to stabilize work that
has already been done and cut down on experiments
Am 10.03.2013 20:56, schrieb David Kastrup:
Marc Hohl m...@hohlart.de writes:
Am 10.03.2013 18:32, schrieb David Kastrup:
Ok folks, it is this time of the year again: I am trying to make myself
unpopular.
[...]
So I want to see 2.18 soon. That means we need to stabilize work that
has
m...@mikesolomon.org writes:
On 10 mars 2013, at 18:54, David Kastrup d...@gnu.org wrote:
m...@mikesolomon.org m...@mikesolomon.org writes:
On 10 mars 2013, at 18:32, David Kastrup d...@gnu.org wrote:
Ok folks, it is this time of the year again: I am trying to make
myself
On 10 March 2013 20:56, David Kastrup d...@gnu.org wrote:
I think there have been two issues crystallized out from it.
a) \bar |: and \bar :| are a frequent cause for surprise, and the
return value one gets for dealing with that surprise, a direct way
for specifying the desired look
So, to resume, I agree that a freeze is important. When the freeze
kicks in, I'd rather that we say something like no new big projects
starting on date X will be part of 2.18 so that developers can plan
out their next few months accordingly.
+1
Werner
Xavier Scheuer x.sche...@gmail.com writes:
On 10 March 2013 20:56, David Kastrup d...@gnu.org wrote:
I think there have been two issues crystallized out from it.
a) \bar |: and \bar :| are a frequent cause for surprise, and the
return value one gets for dealing with that surprise, a
Werner LEMBERG w...@gnu.org writes:
So, to resume, I agree that a freeze is important. When the freeze
kicks in, I'd rather that we say something like no new big projects
starting on date X will be part of 2.18 so that developers can plan
out their next few months accordingly.
+1
Well,
I just put out the announcement because I feel we should now stop
accumulating stuff that will require half a year to reach a stable
state. We need to focus on dealing with what we have in the queue
right now rather than heaving new things into master that will be
beneficial to end users
On 10 March 2013 22:05, David Kastrup d...@gnu.org wrote:
(snip)
If a refined interface can defuse these cases as well, it would
certainly seem like a good step to take.
Thank you for this wise message.
Well, the question is always the balance between gain and pain. Where
the pain is not
Werner LEMBERG w...@gnu.org writes:
I just put out the announcement because I feel we should now stop
accumulating stuff that will require half a year to reach a stable
state. We need to focus on dealing with what we have in the queue
right now rather than heaving new things into master that
Hi,
On Sun, Mar 10, 2013 at 6:32 PM, David Kastrup d...@gnu.org wrote:
Ok folks, it is this time of the year again: I am trying to make myself
unpopular.
I want to see 2.18 soon. That means we need to stabilize work that
has already been done and cut down on experiments in the master
Werner LEMBERG w...@gnu.org writes:
So, to resume, I agree that a freeze is important. When the freeze
kicks in, I'd rather that we say something like no new big projects
starting on date X will be part of 2.18 so that developers can plan
out their next few months accordingly.
+1
40 matches
Mail list logo
