Re: release bugs [was Re: Processed: enriched.el code execution]

[Fabrice Popineau <fabrice.popineau@centralesupelec.fr>]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

Maybe I am naive, but I don't see why a bug existing in previous releases
should be blocking.
If the bug exists in say emacs 25.1, blocking the release of 26.1 will not
prevent
people to be at risk because they will continue to use 25.1.
I would say that only newly introduced bugs for example related to new
features or refactoring
should be considered to be blocking.

Fabrice



2017-09-08 9:11 GMT+02:00 Paul Eggert <eggert@cs.ucla.edu>:

> Eli Zaretskii wrote:
>
>> marking bugs as blocking and their
>> urgency are two different and almost independent issues.
>>
>
> They are different but not that independent. Urgent bugs are considerably
> more likely to be blocking (i.e., they should be fixed before the next
> release) than non-urgent bugs are.
>
> so why bother to mark any bug as blocking?
>>>
>> Because it helps in management of a release.  It's a managerial tool.
>>
>
> Yes, of course. It's just that this particular bug is severe enough that
> it should be fixed before the next release. I'm even becoming to be
> inclined to think that it should be backported to the *previous* release,
> and I *hate* doing that sort of thing.
>
>


-- 
Fabrice Popineau
-----------------------------
CentraleSupelec
Département Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------

[-- Attachment #2: Type: text/html, Size: 2757 bytes --]