Hello Ekaitz, Am Sat, May 10, 2025 at 01:04:18PM +0200 schrieb Ekaitz Zarraga: > So, now, realistically speaking, we are not ready for total automation and > we should make a release process. That I agree with, and we could use the > process to try to slowly make the process lighter until it barely exists, > which would at some point let us make releases more often and with lower > effort. > (...) I'm thinking on how could we share > the responsibility to make the work of those that are going to make the > release as light as possible.
I think this is something we agree upon: Things should be as automatic as possible, if we can make machines do the work for us, this would be perfect! But clearly this is not easy. Given past problems with CI and QA, we see that there are not enough people working on automation, and that the problems are complex. > I'm a little bit pessimistic about how many people would get involved in > that, or better said: I'm worried that the very same people would be the > ones that get involved in the process over and over again. Indeed, the idea is to have a turn-over, which is partially spelt out in the proposal. If everybody takes part twice and there is a renewal of half of the people every time, we would avoid that people get burnt out and still pass on experiences with the process. > That's why I'm trying to find a way to make everybody get involved in the > process in their everyday work, so the actual release process is not that > hard and makes it more likely to people to join. Good point, which maybe should not be a part of this GCD, but a subject of further thought: How can we make our life easier? How can we improve the quality of Guix? When Ludovic added the deprecation policy to the manual, I suppose that was something he had in mind. Similarly it is the goal of the Codeberg migration. > I like the GCD, I think it's thoughtful and well organized, but it might > lack some of that: let's see how it went and try to make it lighter and > lighter for the future. The GCD contains step 14: "Release retrospective". That covers your point, in my opinion. But more fundamentally, I think it is not realistic to end up with a fully automatic procedure. In the end Guix is a social endeavour (lots of people working together towards a common goal), and I think we need social processes to reach our goals. For instance, when merging team branches, we somehow need to negotiate the order; individual teams will look at their branches and try to advance them, but sometimes it may be better to let another branch go to the front. Similarly for a release, decisions will have to be made. Packages may have to be dropped, the latest release of desktop environment X which is almost, but not quite, ready may have to be excluded, and so on. Having a team to coordinate this, and also invested to take unpopular decisions, is necessary in my opinion. Also I think we need a period of manual testing. As Vagrant said, sometimes packaging for Debian, for instance, reveals problems that we had not seen before. Or asking people to try an installation on an exotic architecture. Andreas
