lilypond-devel
[Top][All Lists]
Advanced

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

Re: release blocked due to issues to verify


From: David Kastrup
Subject: Re: release blocked due to issues to verify
Date: Wed, 08 Feb 2012 11:22:44 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux)

"Phil Holmes" <address@hidden> writes:

> ----- Original Message ----- 
> From: "Graham Percival" <address@hidden>
> To: <address@hidden>
> Cc: "Phil Holmes" <address@hidden>
> Sent: Wednesday, February 08, 2012 9:59 AM
> Subject: release blocked due to issues to verify
>
>
>> It might be nice to have a release later today, as there are 5
>> Critical fixes either pushed or waiting to be pushed.
>>
>> Unfortunately,
>> http://code.google.com/p/lilypond/issues/list?can=7
>> shows some issues which do *not* contain "fixed_2_15_29", so I
>> will not make a release.
>>
>> In case you forgot, the requirements are here:
>> http://lists.gnu.org/archive/html/bug-lilypond/2012-02/msg00081.html
>>
>> - Graham
>
>
> Those are all patches which only actually appear in 15.29 - so we have
> 2 options - label them correctly or verify them anyway.  Waddya want?

You can't verify what has not been in a release.  Obviously, one needs
to check whether the respectively claimed fixes _have_ indeed been
pushed into staging after the release of 2.15.28.

If they have been pushed and the problem _is_ fully fixed, the patch
status needs to get removed (unless there are unapplied patches that
would be important to keep in sight because they might address other
issues even though this issue has been fixed, but that is a side
consideration).

In any case, it must be stated in the comments which commit is
responsible for fixing the problem so that verification can happen.

It is usually the responsibility of the person marking the issue fixed
to also add the fixed_xx_xx label and mention the commit, but if that
has not been done for some reason, I think we have keeping this info
somewhat accurate also marked out as a janitorial task for the bug
squad, sort of mopping up after the developers in case they did not
entirely clean up the mess that might be _easiest_ for them to do right
away, but which still constitutes an _additional_ effort on top of their
"real" work.

-- 
David Kastrup




reply via email to

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