Our practice has been that for a while after a NN.1 release we install bug fixes on the emacs-NN branch, and keep merging it to master, but then as time passes we drift towards only installing things on master, returning to the emacs-NN only if there is a critical bug fix for which we immediately want to do a point release.
I would like us to be more deliberate about how we use the emacs-31 branch after the release of Emacs 31.1, using it in a more principled way. I've CC'd two of our downstreams for feedback. 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. - Continue to install fixes on the emacs-31 branch as though we were still in the later stages of the pre-release freeze. - A halfway house: the second option until the release of Emacs 32.2, which we will expect to do within a few months, and thereafter the first option, with only critical bug fixes permitted. 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. 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. -- Sean Whitton
