Re: Reflections on the release process

["Gábor Boskovits" <boskovits@gmail.com>]

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

Hello Ludo,

Ludovic Courtès <ludo@gnu.org> ezt írta (időpont: 2020. ápr. 22., Sze
22:09):

> Hi!
>
> zimoun <zimon.toutoune@gmail.com> skribis:
>
> > On Wed, 15 Apr 2020 at 22:18, Ludovic Courtès <ludo@gnu.org> wrote:
> >
> >> 4. We lack a clear way to mark bugs as release-critical.  I’m really
> >> happy Florian, Mathieu, and I have been able to work together and squash
> >> 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 prevent
> >> misunderstandings such as regarding the NVMe bug:
> >> <https://issues.guix.gnu.org/issue/40590>.  Can Debbugs help?  The GCC
> >> folks have a system that sends email with an update on the number of
> >> release-critical bugs.  I’m 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’t think Debbugs supports a
> “release-critical” tag, does it?  Or perhaps we could take 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’m 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’s no question we want more than one release per year.  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…).
>
> Once we have that, plus some planning such as marking RC-critical bugs,
> it’ll be easier to make releases IMO.
>
> Thanks,
> Ludo’.
>

Best regards,
g_bor

>
>

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