bug-lilypond
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: issues to verify -> no more releases


From: Graham Percival
Subject: Re: issues to verify -> no more releases
Date: Fri, 3 Feb 2012 12:57:21 +0000
User-agent: Mutt/1.5.21 (2010-09-15)

On Fri, Feb 03, 2012 at 01:14:52PM +0100, David Kastrup wrote:
> Graham Percival <address@hidden> writes:
> 
> > At the time of this writing, this means that if *ANY* issue on this
> > list:
> > http://code.google.com/p/lilypond/issues/list?can=7
> > does *NOT* say "fixed_2_15_28", there will be no release.
> 
> "verifying" an issue is not the same as giving a "fixed_*" marking.

Yes.

Programmers gives things fixed_* tags.

Bug squad tests those fixes, or asks for help if necessary, then
changes the status of those fixed items to Verified.

> So I don't quite understand what you expect here.  I can put the
> respective "fixed" markers corresponding to the respective
> commits on (which is what I do unless I forget whenever marking
> an issue of mine fixed after pushing).

>From you: nothing (other than the "in general" category)

>From the bug squad: to do their job.  This goes back years.
http://lists.gnu.org/archive/html/bug-lilypond/2010-08/msg00417.html

>From the lilypond community in general, be they developers or
users: if the current bug squad cannot handle this task, then
either encourage (with moral support, monetary support, or immoral
support) them to work for more than 20 minutes once a week, or
offer to join the bug squad and do this work yourself.

> Or is your problem that you want to see "Verified" on every committed
> fix with a version earlier than 2.15.18, making sure that the commit did
> indeed make it into the mentioned release?

2.15.28, not 2.15.18, but yes.  If we don't know that stuff that
was claimed to be fixed in .27... or .25.... or .23... is working,
then I'm not going to bother putting out .28.


Note that for a "patch" issue, verifying is as simple as checking
that the commit is in git.  For actual bug issues, just run the
bloody minimal example in GUB 2.15.27.  For other stuff, take
bloody initative and ask for help.

For example, 2239 google code only returns 20...   is a bit
outside of our normal bug range.  So bring that to the attention
of -devel, and I'll say it can just be marked Verified instantly
because it's not worth fussing about it.

- Graham



reply via email to

[Prev in Thread] Current Thread [Next in Thread]