Hi, Gabriel Wicki <[email protected]> writes:
> Hey! > > On Fri, Feb 20, 2026 at 11:31:35AM +0900, Maxim Cournoyer wrote: >> In my opinion the release process should be adjusted to impact the least >> possible the ongoing activities; I think using a release branch to >> prepare the release would achieve this, relieving the need to carefully >> communicate (and enforce) some code freeze on the master branch. > Sorry, Maxim, but this is not really relevant to this discussion. We > (as a project) sometimes need to address issues with committers and the > current state of the art fails at this. Changing the release process > could (maybe) address this one particular thing, but—as we discussed at > Guix Days—we might not want to complicate the release process more than > it already is. I pointed it out because it seemed like this was the origin of the perceived problem you're trying to solve. The point I was trying to make was that we have to recognize that we are a rather large community living across many time zones, and that expecting a synchronous-kind of reply from the whole group is not realistic. It's a human problem, not a technology problem. Thus, my suggestion was to try to reduce the events that require careful synchronization, such as a freeze on the main branch. [...] >> I tried Zulip before and it worked well, but personally, I'd prefer to >> keep the little email I have left. Communication is best done by email >> in my opinion. > I actually agree, but I think we could (at least) use some indication in > our subject lines when we address specific issues or need to reach > people in time. Maybe something like: > >> Subject: [COMMITTERS] Take note of the master branch freeze Sure, why not :-). Or if it's really important, as someone else suggested, we could even message all the committers directly (though that shouldn't be abused). That may not be easy right now, but we could have for example a mail entry for the people registered in .guix-authorization file, that etc/teams.scm could present in a convenient way to send an email. For comparison, how would Zulip solve that problem? You would also need to define a group/alias for the committers, I assume? [...] >> I also like the more transparent archival property of emails, and that >> it doesn't force you into creating yet another account. > Honestly, the archival property of our mailing lists blows and is one of > the reasons why Zulip is being suggested. The nice thing about mailing list is that the data is out there for anyone to use, and there are typically various frontends to access/search it. For Guix/Guile there is Yhetil (https://yhetil.org/guix/) which is hosting public-inbox instance. I think it's good! > I again agree on the account > creation thing. But then—again—we should consider reach (beyond who has > already boarded the hacker's Guix train) and think about scalability and > **community**. We have not one medium where many, most or (dare to > imagine!) all feel welcome, read, take part in discussions. This is > bad. If we want to be a big project that allows as many people as > possible to partake (and this not only means: send in patches but rather > voice their opinions and read important stuff when it happens) then we > absolutely need to open our minds to the problems we currently have. And is email really the problem?. Your introduction to the problem at hand in your original mail: > With the latest release we realized that some messages (like the master > branch freeze) did not reach all committers in time—I for one only read > about that by chance on IRC. That is because I was quite swamped with > $dayjob and only went to codeberg to work off my notifications when I > had time to do that. Reading [email protected] just did not make it to > the top of my personal work stack often enough. Sounds more like "it's inconvenient to me"; extrapolating this to "inconvenient to everyone" sounds like a stretch to me :-). -- Thanks, Maxim
