LGTM
(yeah, i'm quite late)
2011/8/16 Graham Percival :
> On Sat, Aug 13, 2011 at 05:26:09PM +0100, Trevor Daniels wrote:
>>
>> I like Keith's "Needs".
>> This easily extends to several labels if we
>> find that is desirable. Other suggestions:
>
> Thanks, I like "Needs_evidence"; it's general en
On Sun, Aug 21, 2011 at 10:19:23AM +0100, Phil Holmes wrote:
> Think we need to change the description of this on the tracker to
> make it clear it's not just collisions.
ok,done.
Cheers,
- Graham
___
lilypond-devel mailing list
lilypond-devel@gnu.org
- Original Message -
From: "Graham Percival"
* Type-ugly: replaces Type-collision, and it will include
things like bad slurs in addition to actual collision.
Think we need to change the description of this on the tracker to make it
clear it's not just collisions.
--
Phil
LGTM
2011/8/16 Graham Percival :
> Minor update for clarity and discussion from the past few days.
> We're aiming to accept the final proposal on Thursday.
> http://lilypond.org/~graham/gop/gop_8.html
>
>
> ** Proposal summary
>
> Let’s get rid of priorities. We will simply describe bugs in
> neut
On Tue, Aug 16, 2011 at 11:20:02AM +0100, Ian Hulin wrote:
> 1. Some nit-picky stuff to make the proposal crystal-clear to
> skim-readers like me.
> See comments below embedded in the your original message text.
Thanks, all fixed.
> 2. I'd like to consider two types to use as additional info to t
-PROP 8: issue priorities (probable 2)
Minor update for clarity and discussion from the past few days.
We're aiming to accept the final proposal on Thursday.
http://lilypond.org/~graham/gop/gop_8.html
** Proposal summary
Let’s get rid of priorities. We will simply describe bugs in
neutral
Hi Graham,
1. Some nit-picky stuff to make the proposal crystal-clear to
skim-readers like me.
See comments below embedded in the your original message text.
2. I'd like to consider two types to use as additional info to the
current ones: Type-User-development and Type-Developer-development.
2.1
Graham Percival wrote Tuesday, August 16, 2011 5:51 AM
Minor update for clarity and discussion from the past few days.
We're aiming to accept the final proposal on Thursday.
http://lilypond.org/~graham/gop/gop_8.html
LGTM
Trevor
-
No virus found in this message.
Checked by AVG - www.
Minor update for clarity and discussion from the past few days.
We're aiming to accept the final proposal on Thursday.
http://lilypond.org/~graham/gop/gop_8.html
** Proposal summary
Let’s get rid of priorities. We will simply describe bugs in
neutral terms; each contributor can search and interp
On Sat, Aug 13, 2011 at 05:26:09PM +0100, Trevor Daniels wrote:
>
> I like Keith's "Needs".
> This easily extends to several labels if we
> find that is desirable. Other suggestions:
Thanks, I like "Needs_evidence"; it's general enough to apply to
"we need to be able to reproduce the bug", "we n
Am Monday, 15. August 2011, 21:36:58 schrieb Graham Percival:
> I know that there's some dissatisfaction with the way that
> "invalid/duplicate/verified" works, but that relies on google's
> infrastructure, and I'm not certain if anybody has bothered to
> follow this up with google yet.
http://cod
On Mon, Aug 15, 2011 at 03:00:05PM +0300, Dmytro O. Redchuk wrote:
> On Wed 10 Aug 2011, 09:46 Graham Percival wrote:
> > In case you're wondering: yes, I am serious proposing that we
> > elminiate priorities completely, and this is not a joke. Nobody
>
> Do we want to discuss labels -- backport/
On Mon, Aug 15, 2011 at 02:56:21PM +0300, Dmytro O. Redchuk wrote:
> On Wed 10 Aug 2011, 09:46 Graham Percival wrote:
> > ** More new/changed types
>
> No type-documentation any more? Why? Sorry, I've jumped a bit late thought.
That was only a list of changed types. Anything left unmentioned
(i.
On Wed 10 Aug 2011, 09:46 Graham Percival wrote:
> In case you're wondering: yes, I am serious proposing that we
> elminiate priorities completely, and this is not a joke. Nobody
Do we want to discuss labels -- backport/invalid/invalid-verified/etc-etc
or like that, as this was discussed a bit in
On Wed 10 Aug 2011, 09:46 Graham Percival wrote:
> ** More new/changed types
>
> * Type-crash: any segfault, regardless of what the input file
> looks like or which options are given. Disclaimer: this
> might not be possible in some cases, for example certain
> guile programs
On Wed 10 Aug 2011, 22:04 Colin Campbell wrote:
> On 11-08-10 10:46 AM, Graham Percival wrote:
> > * Type-ignorance: (fixme name?) it is not clear what the
> > correct output should look like. We need scans, references,
> > examples, etc.
> >
>
> Perhaps more diplomatically as "Typ
Graham Percival wrote Thursday, August 11, 2011 8:41 PM
On Thu, Aug 11, 2011 at 12:32:09PM -0700, Keith OHara wrote:
On Wed, 10 Aug 2011 22:06:16 -0700, Graham Percival
wrote:
On Thu, 11 Aug 2011 00:02:51 -0700, Trevor Daniels
wrote:
>>>Graham Percival percival-music.ca> writes:
Graham Percival writes:
> On Sat, Aug 13, 2011 at 07:12:53AM +0200, David Kastrup wrote:
>> Keith OHara writes:
>>
>> > Issue 1809 is an interesting test of this policy. `make test`
>> > sometimes crashes for some programmers, making it very hard for them
>> > to contribute, but it crashes in
David Kastrup wrote Saturday, August 13, 2011 6:12 AM
It crashes because the internal garbage collector data structures
have
been clobbered. Which is likely due to some Lilypond code problem
(like
data available too early for collection). So it is likely that we
are
not "powerless to resolv
On Sat, Aug 13, 2011 at 07:12:53AM +0200, David Kastrup wrote:
> Keith OHara writes:
>
> > Issue 1809 is an interesting test of this policy. `make test`
> > sometimes crashes for some programmers, making it very hard for them
> > to contribute, but it crashes in the Guile garbage collection, so
Keith OHara writes:
> Graham Percival percival-music.ca> writes:
>
>>
>> We will make a “Type-Critical”; a new stable release will only
>> occur if there are 0 type-Critical issues.
>>
> [...]
>> it also attracts the attention of potential
>> contributors, so we should avoid having any glaring
Graham Percival percival-music.ca> writes:
>
> We will make a “Type-Critical”; a new stable release will only
> occur if there are 0 type-Critical issues.
>
[...]
> it also attracts the attention of potential
> contributors, so we should avoid having any glaring problems which
> would stop some
On Thu, Aug 11, 2011 at 12:32:09PM -0700, Keith OHara wrote:
> On Wed, 10 Aug 2011 22:06:16 -0700, Graham Percival
> wrote:
>
> On Thu, 11 Aug 2011 00:02:51 -0700, Trevor Daniels
> wrote:
>
> >>>Graham Percival percival-music.ca> writes:
> * Type-ignorance: (fixme name?) it is not c
On Wed, 10 Aug 2011 22:06:16 -0700, Graham Percival
wrote:
On Thu, Aug 11, 2011 at 04:59:02AM +, Keith OHara wrote:
Graham Percival percival-music.ca> writes:
> Type-critical:
>
You might want to split this into two:
regressions to the output of Lilypond, and
critical impediments to d
Graham Percival wrote Thursday, August 11, 2011 6:06 AM
On Thu, Aug 11, 2011 at 04:59:02AM +, Keith OHara wrote:
Graham Percival percival-music.ca> writes:
> * Type-ignorance: (fixme name?) it is not clear what the
> correct output should look like.
In a classification of Typ
On Thu, Aug 11, 2011 at 04:59:02AM +, Keith OHara wrote:
> Graham Percival percival-music.ca> writes:
>
> > Type-critical:
> >
> You might want to split this into two:
> regressions to the output of Lilypond, and
> critical impediments to development
Why bother splitting it? I forsee an
Graham Percival percival-music.ca> writes:
> Type-critical:
>
You might want to split this into two:
regressions to the output of Lilypond, and
critical impediments to development
> * Type-ignorance: (fixme name?) it is not clear what the
> correct output should look like.
In a cl
On 11-08-10 10:46 AM, Graham Percival wrote:
* Type-ignorance: (fixme name?) it is not clear what the
correct output should look like. We need scans, references,
examples, etc.
Perhaps more diplomatically as "Type- ambiguous"?
Colin
--
The human race has one really effecti
On 8/10/11 10:46 AM, "Graham Percival" wrote:
> I'm feeling pretty good about this one, with the exception of
> whether we should have a Type-ignorance or not.
>
> In case you're wondering: yes, I am serious proposing that we
> elminiate priorities completely, and this is not a joke. Nobody
On Wed, Aug 10, 2011 at 06:44:51PM +0100, Trevor Daniels wrote:
>
> Graham, you wrote Wednesday, August 10, 2011 5:48 PM
>
> >Completely agreed! I've taken a stab at this with the "stamp of
> >approval" concept of a release -- please take a look at the
> >updated GOP-PROP 8...(probable decision)
Graham, you wrote Wednesday, August 10, 2011 5:48 PM
On Wed, Aug 10, 2011 at 10:32:01AM +0100, Trevor Daniels wrote:
Don't get me wrong. Whether we place these issues in a
critical category or not is hardly a vital decision, but here
we're talking about deciding Policy. Policy decisions
mu
On Wed, Aug 10, 2011 at 10:32:01AM +0100, Trevor Daniels wrote:
>
> Graham Percival wrote Wednesday, August 10, 2011 9:09 AM
>
> >Using lily-git.tcl and being able to fix it are completely
> >different things. IIRC the only people who have worked on
> >lily-git.tcl are the original author of it,
I'm feeling pretty good about this one, with the exception of
whether we should have a Type-ignorance or not.
In case you're wondering: yes, I am serious proposing that we
elminiate priorities completely, and this is not a joke. Nobody
has objected yet, but if you don't think this is a good idea,
Graham Percival wrote Wednesday, August 10, 2011 9:09 AM
On Tue, Aug 09, 2011 at 09:27:07AM +0100, Trevor Daniels wrote:
Wouldn't work. Few, if any, developers use lily-git.tcl so
are unlikely to be in a position to fix it.
Using lily-git.tcl and being able to fix it are completely
differ
On Tue, Aug 09, 2011 at 09:27:07AM +0100, Trevor Daniels wrote:
>
> Jan Warchoł wrote Tuesday, August 09, 2011 12:27 AM
> >Because having some issue officially block stable release is the
> >only
> >way of seriously pushing developers to fix it?
>
> Wouldn't work. Few, if any, developers use lil
Jan Warchoł wrote Tuesday, August 09, 2011 12:27 AM
2011/8/8 Trevor Daniels :
Graham Percival wrote Monday, August 08, 2011 6:06 AM
Type-critical:
* anything which stops contributors from helping out (e.g.
lily-git.tcl not working, source tree(s) not being
available). To limit this scope of
2011/8/8 Trevor Daniels :
>
> Graham Percival wrote Monday, August 08, 2011 6:06 AM
>> Type-critical:
>> * anything which stops contributors from helping out (e.g.
>> lily-git.tcl not working, source tree(s) not being
>> available). To limit this scope of this point, we will
>> assume
On Mon, Aug 08, 2011 at 10:50:02PM +0100, Trevor Daniels wrote:
>
> Graham Percival wrote Monday, August 08, 2011 6:06 AM
>
> > * anything which stops contributors from helping out (e.g.
> > lily-git.tcl not working, source tree(s) not being
> > available). To limit this scope of this p
Graham Percival wrote Monday, August 08, 2011 6:06 AM
** Proposal summary
Let’s get rid of priorities. We will simply describe bugs in
neutral terms; each contributor can search and interpret the
results as he or she sees fit.
This is a better approach than haggling over priority.
We will
Thanks for the discussion so far! Based on that, I have a
radically different proposal.
http://lilypond.org/~graham/gop/gop_8.html
** Proposal summary
Let’s get rid of priorities. We will simply describe bugs in
neutral terms; each contributor can search and interpret the
results as he or she s
2011/8/6 David Kastrup :
> Jan Warchoł writes:
>
>> 2011/8/6 James Lowe :
>>> Users and new contributors will interpret priority as importance,
>>> though, and will naturally want their favorites to be higher on the
>>> list. That's why I suggested putting issues where we don't know
>>> exactly w
On Sat, 06 Aug 2011 00:13:49 -0700, Jan Warchoł
wrote:
2011/8/6 Keith OHara :
"order in which the project encourages
contributors to attack issues".
Sounds good to me. Still, decision depends on our views about
relative importance of user needs vs. developer needs.
Decision of the contri
On 06/08/11 08:47, David Kastrup wrote:
> The compromises between the wishes of people and the technical feasible
> things and those you want to do are a moving target. And the
> responsibility for making technical and logical impossibilities
> disappear, to match the program better to expectation
Hello,
> But any interpretation of "priority" in the sense of "importance" seems
> useless. We differ quite a lot in our opinions of importance. I suspect
> Janek and I would rank issues in near-opposite order of importance. That
> means that any importan
Jan Warchoł writes:
> 2011/8/6 James Lowe :
>
>> Users and new contributors will interpret priority as importance,
>> though, and will naturally want their favorites to be higher on the
>> list. That's why I suggested putting issues where we don't know
>> exactly what Lilypond should do, as "Pos
2011/8/6 James Lowe :
> We don't have a GOP for 'isn't there a better way to keep track of issues AND
> upload patches' I see though.
We have, but it's not yet put on schedule.
http://lilypond.org/doc/v2.15/Documentation/contributor/policy-decisions
2011/8/6 Keith OHara :
> I suspect Graham mea
On Wed, 03 Aug 2011 15:42:55 -0700, Graham Percival
wrote:
On Tue, Aug 02, 2011 at 07:48:12AM +, Keith OHara wrote:
I'm curious first what we want the "priority" field to mean.
[...]
The more that I think about it, the more I like this
interpretation of the Priority field.
What inter
On Fri, Aug 05, 2011 at 10:12:26PM +, James Lowe wrote:
> It probably annoys some because they then feel obligated but
> this is where I think GOP 8 blurs over to GOP 7. I get a bit
> exhausted keeping track of it all which is a negative thing,
...
> We don't have a GOP for 'isn't there a bett
Hello,
)usually it's longer). I noticed that when i have too many issues open
)(including Frog's issues which i 'supervise' and upload to Rietveld), i'm
)getting confused; i cannot remember what's going on where (because
)discussions last for a long time) and so on.
)Therefore i have to wait unti
2011/8/2 Graham Percival :
> There is a long history of "good programs never crash". I think
> we should take part in that.
+1
> Improvements to our development process won't be finished until
> the end 2011; I think it's irresponsible to actively recruit
> people until then.
Do you mean that w
On 2 August 2011 10:28, Phil Holmes wrote:
>
> So any bug in Lily that produces bad output can never be High? Or - to put
> it another way, we, the developers ,only regard bugs as high when they
> hinder us, not when they make you, the user's life difficult. I don't like
> that. I remain of the
On Tue, Aug 02, 2011 at 07:48:12AM +, Keith OHara wrote:
> I'm curious first what we want the "priority" field to mean.
>
> Probably we do not mean literally the priority with which contributors will
> give attention to the bugs, because contributors are volunteers driven by
> individual int
On Tue, Aug 02, 2011 at 10:37:18AM +0200, David Kastrup wrote:
> Actually, I read this first as "bugs in undocumented features can't have
> high priority", carrying the message "if you don't document your new
> feature, we refuse to make fixing problems with it a high priority".
I wasn't going for
On Tue, Aug 02, 2011 at 07:48:12AM +, Keith OHara wrote:
>
> I'm curious first what we want the "priority" field to mean.
Ding ding, I think we have a winner. That sentence is the crux of
the whole thing.
> Probably we do not mean literally the priority with which contributors will
> give
- Original Message -
From: "James Lowe"
To: "Phil Holmes" ; "Graham Percival"
;
[snip]
)> Priority-postponed:
)>
)>* No fix expected for at least two years.
)
)I don't actually see the point of this, given that I can find open high
)priority issues almost 5 years old. Think we
priorities
)
)- Original Message -
)From: "Graham Percival"
)To:
)Cc: "Phil Holmes"
)Sent: Tuesday, August 02, 2011 6:22 AM
)Subject: GOP-PROP 8: issue priorities
)
)
)
)> We have over 600 open bugs or patches to review. At one point,
)> this number was in the low 60
Graham Percival writes:
> Priority-medium:
>
> * highest level for graphical output problems
> * highest level for undocumentated new features
Actually, I read this first as "bugs in undocumented features can't have
high priority", carrying the message "if you don't document your new
fe
- Original Message -
From: "Graham Percival"
To:
Cc: "Phil Holmes"
Sent: Tuesday, August 02, 2011 6:22 AM
Subject: GOP-PROP 8: issue priorities
I'm expecting a moderate amount of discussion for this one.
http://lilypond.org/~graham/gop/gop_8.html
**
Graham Percival percival-music.ca> writes:
> ** Rationale
>
> Bug squad members are confused, users are confused, and (to a
> certain extent) Graham just makes up the rules for “Critical” as
> he goes along. Let’s get some clarity here.
>
> Giving priority to issues which hinder development may
On Tue, Aug 02, 2011 at 07:22:33AM +0100, m...@apollinemike.com wrote:
> On Aug 2, 2011, at 6:22 AM, Graham Percival wrote:
>
> >* any segfault, regardless of what the input file looks like
> > or which options are given.
>
> I like the first one, but I think the second needs to be tweak
On Aug 2, 2011, at 6:22 AM, Graham Percival wrote:
> ** Proposal details
>
> Priority-critical:
>
>* a reproducible failure to build either make or make doc,
> from an empty build tree, in a first run, if configure does
> not report any errors.
>* any segfault, regardless of wh
I'm expecting a moderate amount of discussion for this one.
http://lilypond.org/~graham/gop/gop_8.html
** Proposal summary
At the moment, a stable release is entirely dependent on the
number of Critical issues, but there’s some questions about
precisely what a “Critical issue” should be. Clarit
62 matches
Mail list logo
