> From: Spencer Baugh <[email protected]>
> Date: Fri, 26 Jun 2026 13:31:48 -0400
> Cc: Sean Whitton <[email protected]>, [email protected],
> [email protected], [email protected]
>
> On Fri, Jun 26, 2026 at 7:28 AM Eli Zaretskii <[email protected]> wrote:
> >
> > > From: Sean Whitton <[email protected]>
> > > Cc: [email protected], [email protected],
> > > [email protected]
> > > Date: Fri, 26 Jun 2026 10:11:03 +0100
> > >
> > > Eli Zaretskii [25/Jun 6:17pm +03] wrote:
> > > > Numbers to back the impression that "our NN.1 releases always feel
> > > > like they take longer than we would like". Can you take the part of
> > > > etc/HISTORY since Emacs 26.1 and tell what kind of schedule you'd like
> > > > to see instead?
> > >
> > > Emphasis on the "feel" -- I didn't mean to claim that they actually do
> > > take longer than is reasonable, my point was that they feel like they
> > > do.
> > >
> > > >> We could say that we stop doing this as soon as the next branch is cut.
> > > >
> > > > Sorry: stop doing what?
> > >
> > > I meant: if we were to go with the plan where we continue to install all
> > > safe fixes on the release branch, we could stop making new
> > > (non-critical) point releases from it at the point at which we cut the
> > > new release branch.
> >
> > If we don't make releases from a branch, what's the point of
> > installing fixes on it? I'm probably missing something.
> >
> > > > The main point, I think, is this: will keeping the release branch
> > > > alive for longer delay the start of the release cycle for NN+1.1? It
> > > > might do that for reasons of manpower and resources we have, if
> > > > nothing else.
> > >
> > > I agree that this is the main point. It would be good to have some
> > > others chime in, I'm really not sure myself.
> >
> > The number of people who have real-life experience in these matters is
> > quite limited 😉. When in doubt, we could just try something and then
> > draw our conclusions from the experience.
>
> At my site, we use our own emacs-30 branch, and we are continually
> backporting safe fixes from master to our emacs-30 branch. We'll keep
> doing this until emacs-31 is released. We did the same for emacs-29
> and emacs-28.
>
> We do this so we can get fixes more quickly: when a user reports a bug
> internally, and we go fix it on master, we want to be able to deliver
> the fix to the user immediately rather than wait for the next major
> Emacs release.
>
> So I would love to see the emacs-31 branch stay alive longer upstream.
> That would significantly reduce the need for my site-local branch.
IOW, you'd like us to do this job for you, in addition to the many
other duties we already have.
> Since we'd use the upstream emacs-31 branch at my site, that would
> help test the backported bugfixes. Happy to help out in any other way
> I can.
Feel free to come on board and tell when to backport fixes to previous
branches, and then also take care of producing further NN.x release
tarballs from those branches (because backporting fixes without
releasing Emacs with those fixes is just a waste of effort).
IOW, this is a matter of manpower and resources. We need more of that
to be able to do the followings (in addition to a lot of duties the
head maintainers already have and do, which you as a downstream distro
don't have):
. examine each bugfix and decide whether it is relevant to older
major releases, and if so, is it safe enough to include there
. produce tarballs from previous branches after enough bugfixes
accumulated (or maybe even after each fix)
Volunteers are welcome to take over these parts.
