Eli Zaretskii [24/Jun 6:10pm +03] wrote: >> Here are some ways we could go: >> >> - Decide that only critical bug fixes go on the emacs-31 branch. >> Stop putting other bug fixes there are soon as Emacs 31.1 is out. >> "Critical" means we want to do a point release as soon as the fix is >> installed. > > IOW, if there are no critical bugs, we never release Emacs 31.1, but > go directly to starting the Emacs 32 release cycle?
Emacs 31.2* as you followed up, but yes. >> - Continue to install fixes on the emacs-31 branch as though we were >> still in the later stages of the pre-release freeze. > > That's what we've been doing until now on every release branch after > the NN.1 version was released. It isn't though, and that's my point. We do that for a while and then gradually do it less and less, with no rhyme or reason for the process. >> - A halfway house: the second option until the release of Emacs 32.2, > > You mean 31.2? Yes. >> which we will expect to do within a few months, and thereafter the >> first option, with only critical bug fixes permitted. > > Theoretically, we've intended to do it this way, but actually ended up > doing the previous one. I see, interesting. >> The advantage of the second two options is that our users would get >> fixes for various bugs much -- years -- sooner than they otherwise >> would. That's a service that it would be nice to provide, if we could. > > Not sure I understand why. Presumably, you mean we should install on > the release branch fixes that are not-so-safe, instead of installing > them on master? If so, we tried that before Emacs 26 (I think), and > the results were unsatisfactory: the fixes would destabilize the > release branch and bring new bugs. Which is why we switched to the > current MO. > > Or did I misunderstand what you meant here? No, I only meant safe fixes -- but then users would get those safe fixes years sooner than otherwise. Lots of our fixes are safe. >> The costs would be: >> - for everyone: having to wait for one of the head maintainers to okay >> installing something on emacs-31 instead of just going ahead and >> installing it on master >> - for the head maintainers: having to make those decisions regularly for >> a longer period than just during our feature freezes >> - for the head maintainers: cutting more pretests and point releases >> than at present. >> >> Have I missed anything here? >> >> I think that the cost of cutting more pretests and point releases is >> acceptable. I'm happy to do it and I want to script more of the process >> than is currently automatic at present, anyway. >> >> The other two costs I'm not sure about. > > I think the main cost, one you haven't mentioned, will be to delay the > NN+1.1 release (because more important changes are being installed on > the release branch, and more energy is directed towards emacs-NN > branch releases). I agree that this would be a cost, but it doesn't seem to me like it would be the main cost. Our NN.1 releases always feel like they take longer than we would like, and I don't think this would add a lot. > Also, our experience is that as time passes, it becomes harder and > harder to keep releasing from emacs-NN without adding new features, > because the world at large doesn't stand still. For example, when > Unicode releases a new version of the standard, is it reasonable to > put out emacs-NN.x releases that support only the previous version of > Unicode? IOW, once the release branch is open to anything but > strictly safe bugfixes, and it lives for a long time, it becomes > harder to keep it stable. I think it should still only be strictly safe bug fixes, the difference is that we include strictly safe bug fixes for bugs that are of less critical severity -- how bad the bug is for users and how safely it can be fixed vary indepedently. -- Sean Whitton
