Re: Scheduling a new release?
Am Tue, May 14, 2024 at 11:41:26AM +0200 schrieb Ludovic Courtès: > As discussed at the 2023 Guix Days (!), we could follow a model similar > to that of NixOS: form a release team (~4 people) dedicated to keeping > track of issues in particular wrt. the installer, and committed to > publishing a release within 4–6 months. (I think several people actually > volunteered back in Feb. 2023. :-)) That is a good approach, of course. The two things I think should happen before a release is merging core-updates, and making a rebuild round (or several rounds? I am unsure whether it is safe to do everything at once) ungrafting everything. Plus testing the installer etc. Andreas
Re: Scheduling a new release?
Christina O'Donnell writes: > On 08/05/2024 14:01, Christopher Baines wrote: >> I think it would be nice to have a new release, and indeed release more >> often, I think the way to get there is for less things to be broken >> between releases, such that releasing takes less effort in terms of >> testing and fixing things. >> >> To give some specific issues, I've run up against the recent issues with >> nss [1][2] and I don't think we could release with the nss package as is >> currently. >> >> 1: https://issues.guix.gnu.org/70662 >> 2: https://issues.guix.gnu.org/70663 > > I can fix these by disabling tests, but I would prefer if someone with > more experience packaging for guix could make a decision on > it. Otherwise, I don't have any problem reducing the number of tests > and disabling all tests on PowerPC at least. > > I could also do some analysis if it was deemed necessary, inserting a > patch to measure the timings of each test/cycle. Additionally, I could > try packaging some of the versions between 0.88 and 0.98 to identify > the exact change that could be to blame. However, both of these seem > overkill, given the backlog of patches/issues we have left to get > through, and the manpower we currently have to work with. > > Would any of that be helpful? The problem described by #70663 has now been fixed on master through the changes in #70693. The general point I was making though is that if we can improve tooling and processes so that problems are spotted before they reach master, then releasing should be easier. signature.asc Description: PGP signature
Re: Scheduling a new release?
Hi, On 08/05/2024 14:01, Christopher Baines wrote: I think it would be nice to have a new release, and indeed release more often, I think the way to get there is for less things to be broken between releases, such that releasing takes less effort in terms of testing and fixing things. To give some specific issues, I've run up against the recent issues with nss [1][2] and I don't think we could release with the nss package as is currently. 1: https://issues.guix.gnu.org/70662 2: https://issues.guix.gnu.org/70663 I can fix these by disabling tests, but I would prefer if someone with more experience packaging for guix could make a decision on it. Otherwise, I don't have any problem reducing the number of tests and disabling all tests on PowerPC at least. I could also do some analysis if it was deemed necessary, inserting a patch to measure the timings of each test/cycle. Additionally, I could try packaging some of the versions between 0.88 and 0.98 to identify the exact change that could be to blame. However, both of these seem overkill, given the backlog of patches/issues we have left to get through, and the manpower we currently have to work with. Would any of that be helpful? ... Kind regards, Christina
Re: Scheduling a new release?
Hi Christopher, Christopher Baines skribis: > While releases will still require bursts of effort, I think we need a > more sustainable approach to actually achieve more frequent releases. I think this is largely an organizational problem. As discussed at the 2023 Guix Days (!), we could follow a model similar to that of NixOS: form a release team (~4 people) dedicated to keeping track of issues in particular wrt. the installer, and committed to publishing a release within 4–6 months. (I think several people actually volunteered back in Feb. 2023. :-)) After that, another team, possibly with some overlap, would take over. What matters IMO is to make sure people on the team are not on their own (they coordinate the effort, they don’t fix every single bug by themselves), that they have agency (they decide what goes into the release and what’s left for later), and they do not risk burn-out (it’s a fixed-term mandate). Anyway, I agree it’s high time we published a new release! I would encourage anyone with some experience to volunteer on the team. Again, that doesn’t require expertise on the whole code base but rather a good idea of which teams to talk to and methodology to keep track of things to be done. Thanks, Ludo’.
Re: Scheduling a new release?
Simon Tournier writes: > Here or there, we have bugs as: > > https://issues.guix.gnu.org/70659 > https://issues.guix.gnu.org/70726 > > And our answer looks like: > > > Additionally, I strongly advise upgrading guix-daemon, as noted in > the > > bug report above. > > Well, the bugs appear because the user is upgrading guix-daemon. ;-) > > In both cases (#70659 and #70726), it comes from a fresh install (latest > release v1.4.0) and then the first ’guix pull’ aiming to upgrade all > leads to that reported error. > > Therefore, I strongly advise upgrading latest Guix release. ;-) > > > Although these days I do not have much free time, let make a new release > as soon as possible. WDYT? > > Who’s in? I think it would be nice to have a new release, and indeed release more often, I think the way to get there is for less things to be broken between releases, such that releasing takes less effort in terms of testing and fixing things. To give some specific issues, I've run up against the recent issues with nss [1][2] and I don't think we could release with the nss package as is currently. 1: https://issues.guix.gnu.org/70662 2: https://issues.guix.gnu.org/70663 My hope is that we can spot and potentially address issues like the ones above prior to them affecting master, and thus be more ready to release more often. I think the issue you raise above is also an example of this, a breakage that we can hopefully avoid in the future (through getting the data service to just use builtin:download, discussed in #67250). While releases will still require bursts of effort, I think we need a more sustainable approach to actually achieve more frequent releases. Chris signature.asc Description: PGP signature
Re: Scheduling a new release?
Re, On lun., 06 mai 2024 at 13:12, Simon Tournier wrote: > Although these days I do not have much free time, let make a new release > as soon as possible. WDYT? > > Who’s in? Well, the patch review sessions could be helpful. Maybe we could run some online hackathons. IMHO, having a schedule together would help – at least me ;-) – to keep the flow until crossing the finish line. WDYT? Cheers, simon