Re: Reflections on the release process

[Ludovic Courtès]

Hi!

zimoun <address@hidden> skribis:

> On Wed, 15 Apr 2020 at 22:18, Ludovic Courtès <address@hidden> 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?

> 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’.