Maxim Cournoyer <[email protected]> writes: >> >> They are not held back, they are just merged to a different branch. > > Good point, I had overlooked that. Still, it assumes every of the 47 > current Guix committers will have read this and not make any mistake and > push their large branch to master after it's been built by CI and QA.
This is a problem for sure, but would possibly be solvable by some pre-receive hooks on the server side to reject some pushes? Though, even if there is no enforcement, the number of such mistakes would by definition be lower than number of pushes during normal operations, so from stability point of view, even if not perfect, it should still be an improvement. > Having a distinct release branch would avoid the extra communication > needed here and prevent the unavoidable mistakes. Would this not turn the release branch into an endless Whac-A-Mole of trying to fix stuff? My impression of current state of CI and QA in Guix is — and please correct me if I am wrong — that we cannot really ensure that "new" stuff does not break something. For example system tests are not even a part of the CI. So the release branch would get into working order, the release team would rebase on current master, and it would be (possibly) broken again. Am I overlooking something? Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
