Graham Percival <gra...@percival-music.ca> writes: > On Mon, Jun 25, 2012 at 11:07:38PM +0200, David Kastrup wrote: >> > The release blocking issues could be fixed with minor reverts. >> >> The usual release blockers are not revertible. Even if the current set >> is get cleared out, history tells us that the time window of two weeks >> after unstable release is unlikely to finish before the next detected >> regression. > > Well, we had at least a week when the only release-critical bug > was the po-replace translation thing. It's a bit silly that we > couldn't have a release due to a 5-line texinfo documentation > thing, and in retrospect I should have done a "hostile revert" > (especially since the commit in question didn't go through any > review or countdown). But since the developer survey was coming > up, I didn't want to open any new wounds. Also, I was more sick > of arguments than normal, so again I didn't want to start a new > fight. > > In hindsight I should have reverted it. And if there's no clear > offer to fix it before tomorrow, I'll revert it anyway.
I don't know. Our current release criterion more or less is "everybody is sick of reporting regressions or looking for them, and enough people try looking away to get something out". Stupidities happen. It does not make sense to turn each into a "you are the one who has cost us the stable release" witch hunt. We (TM) have invented the Patchy processes and staging/master in order to have layers separating stupidity from tension creating consequences, causing additional work for computers and humans, but work that can be spread over several people pretty well. Our release policy aims to provide the guarantee that you can upgrade from one stable release to the next without temporary negative consequences, meaning that any change for the worse is intentional and going to stay. The net win we have from that is that we only ever have to maintain or recommend the latest stable version, for all purposes. That goal is not realistic. And the two-week window which we use for deciding whether to call a release candidate a stable release is not related to the typical lifetime of a regression, but rather to the frequency with which we detect old regressions. Of course this number is correlated with the number of regressions (we can't detect regressions that are not there), but the relation is not hard. We need to get away from the situation where our release policies discourage looking for bugs or doing development. A change in that area will have implications on the amount of "stable releases" we are willing to even talk about. But I also think that one prerequisite is more than one person being able to roll a release. "Graham, would you please roll 2.14.4, 2.16.3, and 2.17.15 as soon as possible?" does not really cut it. If we choose to maintain more than one release branch, and in particular more than one stable release branch, we should organise this in a manner where different people can be responsible for different branches. -- David Kastrup _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
