From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.devel Subject: Re: release bugs [was Re: Processed: enriched.el code execution] Date: Fri, 8 Sep 2017 10:20:01 +0200 Message-ID: References: <83tw0h0yem.fsf@gnu.org> <83lglr24ck.fsf@gnu.org> <83wp5azh33.fsf@gnu.org> <87aee030-ec9e-2178-c63c-20e0bd21fa4e@cs.ucla.edu> <838thpznkv.fsf@gnu.org> <9a6bda99-98c6-9bf2-51af-dfd36e763a45@cs.ucla.edu> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114f86dc8beaa80558a93f25" X-Trace: blaine.gmane.org 1504858881 6035 195.159.176.226 (8 Sep 2017 08:21:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 8 Sep 2017 08:21:21 +0000 (UTC) Cc: rgm@gnu.org, Eli Zaretskii , Emacs developers To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 08 10:21:02 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dqEWt-0008RT-1y for ged-emacs-devel@m.gmane.org; Fri, 08 Sep 2017 10:20:47 +0200 Original-Received: from localhost ([::1]:43845 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dqEX0-0004oY-60 for ged-emacs-devel@m.gmane.org; Fri, 08 Sep 2017 04:20:54 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54885) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dqEWq-0004o9-E2 for emacs-devel@gnu.org; Fri, 08 Sep 2017 04:20:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dqEWl-0005wO-Jl for emacs-devel@gnu.org; Fri, 08 Sep 2017 04:20:44 -0400 Original-Received: from smtp2.supelec.fr ([160.228.120.31]:38260) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dqEWa-0005qs-R9; Fri, 08 Sep 2017 04:20:29 -0400 Original-Received: from localhost (localhost [127.0.0.1]) by smtp2.supelec.fr (Postfix) with ESMTP id EADA580575; Fri, 8 Sep 2017 10:20:24 +0200 (CEST) X-Virus-Scanned: amavisd-new at smtp2.supelec.fr Original-Received: from smtp2.supelec.fr ([127.0.0.1]) by localhost (smtp2.supelec.fr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kyIXRq6n-8U1; Fri, 8 Sep 2017 10:20:24 +0200 (CEST) Original-Received: from mail-qk0-f175.google.com (mail-qk0-f175.google.com [209.85.220.175]) by smtp2.supelec.fr (Postfix) with ESMTPSA id 4583E80488; Fri, 8 Sep 2017 10:20:23 +0200 (CEST) Original-Received: by mail-qk0-f175.google.com with SMTP id b82so4641978qkc.4; Fri, 08 Sep 2017 01:20:23 -0700 (PDT) X-Gm-Message-State: AHPjjUjijuTzBELkE//0SCYwBl70jHYKrIvwzvZXPUfw39XRqW2KPFiA LZfRE5Gkfea/qjST+yZ7ny28vnsYBQ== X-Google-Smtp-Source: AOwi7QAA2CaXPNHNV3ylmku8s63GUbpS1uZpC4k4Z06sf26oVmp/gFXvB5VBmzH7yFfNzb8HPykrwgThRdg9GPYWilk= X-Received: by 10.55.139.65 with SMTP id n62mr2659367qkd.94.1504858822402; Fri, 08 Sep 2017 01:20:22 -0700 (PDT) Original-Received: by 10.140.82.21 with HTTP; Fri, 8 Sep 2017 01:20:01 -0700 (PDT) In-Reply-To: <9a6bda99-98c6-9bf2-51af-dfd36e763a45@cs.ucla.edu> X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 160.228.120.31 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:218010 Archived-At: --001a114f86dc8beaa80558a93f25 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 : > 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. > > --=20 Fabrice Popineau ----------------------------- CentraleSupelec D=C3=A9partement Informatique 3, rue Joliot Curie 91192 Gif/Yvette Cedex Tel direct : +33 (0) 169851950 Standard : +33 (0) 169851212 ------------------------------ --001a114f86dc8beaa80558a93f25 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Maybe I am naive, but I don't see why a bug existing i= n previous releases should be blocking.
If the bug exists in say emacs = 25.1, blocking the release of 26.1 will not prevent=C2=A0
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 ref= actoring
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 m= ore likely to be blocking (i.e., they should be fixed before the next relea= se) than non-urgent bugs are.

so why bother to mark any bug as blocking?
Because it helps in management of a release.=C2=A0 It's a managerial to= ol.

 Yes, of course. It's just that this particular bug is severe enough tha= t it should be fixed before the next release. I'm even becoming to be i= nclined to think that it should be backported to the *previous* release, an= d I *hate* doing that sort of thing.




--
Fabrice Popineau
-----------------------------
CentraleSupelec
D=C3=A9partement Informatique
3, rue Joliot Curie
91192 Gif/Yvette Cedex
Tel direct : +33 (0) 169851950
Standard : +33 (0) 169851212
------------------------------
=
--001a114f86dc8beaa80558a93f25--