From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?G=C3=A1bor_Boskovits?= Subject: Re: Reflections on the release process Date: Fri, 24 Apr 2020 18:45:05 +0200 Message-ID: References: <873694o674.fsf@inria.fr> <87y2qns2os.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000002ab8b05a40c1737" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:55378) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jS1S5-0006b8-SU for guix-devel@gnu.org; Fri, 24 Apr 2020 12:45:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.90_1) (envelope-from ) id 1jS1S5-00018v-9M for guix-devel@gnu.org; Fri, 24 Apr 2020 12:45:21 -0400 In-Reply-To: <87y2qns2os.fsf@gnu.org> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane-mx.org@gnu.org Sender: "Guix-devel" To: =?UTF-8?Q?Ludovic_Court=C3=A8s?= Cc: guix-devel --00000000000002ab8b05a40c1737 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello Ludo, Ludovic Court=C3=A8s ezt =C3=ADrta (id=C5=91pont: 2020. =C3= =A1pr. 22., Sze 22:09): > Hi! > > zimoun skribis: > > > On Wed, 15 Apr 2020 at 22:18, Ludovic Court=C3=A8s wrote= : > > > >> 4. We lack a clear way to mark bugs as release-critical. I=E2=80=99m = really > >> happy Florian, Mathieu, and I have been able to work together and squa= sh > >> bugs one by one (thank you!). Still, it would have been better if we > >> could have tagged which is release-critical and which is not, to preve= nt > >> misunderstandings such as regarding the NVMe bug: > >> . Can Debbugs help? The GCC > >> folks have a system that sends email with an update on the number of > >> release-critical bugs. I=E2=80=99m sure we can learn from how others = deal with > >> that. > > > > The first easy step seems to tag the relevant bug as release-critical > > or simply rc. > > Currently, the tags nomal, security, serious, moreinfo, important, > > unreproducible are used in Debbugs. > > Yes, but how do we do that? I don=E2=80=99t think Debbugs supports a > =E2=80=9Crelease-critical=E2=80=9D tag, does it? Or perhaps we could tak= e advantage of > Mumi to add special tags or something? > Actually the description of the severity level serious says its intended meaning is making a bug release critical. I believe we could simply use that. > > Then a second step could be to collect these release critical bugs and > > display them on issues.guix.gnu.org (or data.guix.gnu.org) for example > > remplacing the circle exclamation mark by a red triangle exclamation > > mark (or any really visible symbol). And because the "recent > > activities" is already sorted, it becomes easier to point the > > remaining release critical bugs, the ones stuck, etc. > > Agreed. > > >> For the other issues, I=E2=80=99m interested in any ideas you may have= ! > > > > About the "frozen" window, does it make to schedule it in advance? For > > example a couple of months before. > > And for example, does it make sense to say: at least one release each > > year on the March 14th (Pi day ;-) or approximately. > > Because in general FOSDEM is at the beginning of February and it is a > > big party where some of us come then back home refill of energy, we > > could agree around this date (beginning of Feb.) on the frozen window > > date (say end of February) and then release around middle of March. > > From my point of view, using the Guix Days as catalyst for releasing > > should help the process. > > I think there=E2=80=99s no question we want more than one release per yea= r. For > that to happen, we should make sure the process is well documented, as > smooth as possible, largely automated, and not tied to a single person > (ahem=E2=80=A6). > > Once we have that, plus some planning such as marking RC-critical bugs, > it=E2=80=99ll be easier to make releases IMO. > > Thanks, > Ludo=E2=80=99. > Best regards, g_bor > > --00000000000002ab8b05a40c1737 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello Ludo,

Ludovic Court=C3=A8s <ludo@gnu.org> ezt =C3=ADrta (id=C5=91pont: 2020. =C3= =A1pr. 22., Sze 22:09):
Hi!

zimoun <zimon.toutoune@gmail.com> skribis:

> On Wed, 15 Apr 2020 at 22:18, Ludovic Court=C3=A8s <ludo@gnu.org> = wrote:
>
>> 4. We lack a clear way to mark bugs as release-critical.=C2=A0 I= =E2=80=99m really
>> happy Florian, Mathieu, and I have been able to work together and = squash
>> bugs one by one (thank you!).=C2=A0 Still, it would have been bett= er if we
>> could have tagged which is release-critical and which is not, to p= revent
>> misunderstandings such as regarding the NVMe bug:
>> <https://issues.guix.gnu.org/issue/405= 90>.=C2=A0 Can Debbugs help?=C2=A0 The GCC
>> folks have a system that sends email with an update on the number = of
>> release-critical bugs.=C2=A0 I=E2=80=99m sure we can learn from ho= w others deal with
>> that.
>
> The first easy step seems to tag the relevant bug as release-critical<= br> > or simply rc.
> Currently, the tags nomal, security, serious, moreinfo, important,
> unreproducible are used in Debbugs.

Yes, but how do we do that?=C2=A0 I don=E2=80=99t think Debbugs supports a<= br> =E2=80=9Crelease-critical=E2=80=9D tag, does it?=C2=A0 Or perhaps we could = take advantage of
Mumi to add special tags or something?

Actually the description of the sever= ity level serious says its intended meaning is making a bug release critica= l. I believe we could simply use that.


> Then a second step could be to collect these release critical bugs and=
> display them on issues.guix.gnu.org (or data= .guix.gnu.org) for example
> remplacing the circle exclamation mark by a red triangle exclamation > mark (or any really visible symbol). And because the "recent
> activities" is already sorted, it becomes easier to point the
> remaining release critical bugs, the ones stuck, etc.

Agreed.

>> For the other issues, I=E2=80=99m interested in any ideas you may = have!
>
> About the "frozen" window, does it make to schedule it in ad= vance? For
> example a couple of months before.
> And for example, does it make sense to say: at least one release each<= br> > year on the March 14th (Pi day ;-) or approximately.
> Because in general FOSDEM is at the beginning of February and it is a<= br> > big party where some of us come then back home refill of energy, we > could agree around this date (beginning of Feb.) on the frozen window<= br> > date (say end of February) and then release around middle of March. > From my point of view, using the Guix Days as catalyst for releasing > should help the process.

I think there=E2=80=99s no question we want more than one release per year.= =C2=A0 For
that to happen, we should make sure the process is well documented, as
smooth as possible, largely automated, and not tied to a single person
(ahem=E2=80=A6).

Once we have that, plus some planning such as marking RC-critical bugs,
it=E2=80=99ll be easier to make releases IMO.

Thanks,
Ludo=E2=80=99.

Best regards,
g_bor

--00000000000002ab8b05a40c1737--