Hi Ludo, Thanks to everyone !
On Wed, 15 Apr 2020 at 22:18, Ludovic Courtès <l...@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. 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. > 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. Cheers, simon
