Re: Periodical releases

[Eli Zaretskii <eliz@gnu.org>]

> Date: Mon, 2 Jan 2012 11:40:20 +0100
> From: Carsten Mattner <carstenmattner@googlemail.com>
> Cc: Emacs developers <emacs-devel@gnu.org>
> 
> > These are fairly significant structural changes which are difficult to
> > perform piecemeal and tend to introduce significant breakage which takes
> > months if not years to test&debug (maybe partly for lack of a good
> > regression test suite, but also because of very complex semantics, most
> > of which is the result of accidental interferences between
> > "independent" features).
> 
> The solution for that is to let it evolve in a branch for longer than
> one release cycle

Been there, done that.  In Emacs, this generally means leave the code
to bit-rot into oblivion.  Examples:

  . The person who wrote the multi-tty code disappeared after merging
    the branch onto the trunk; if we would have waited longer with the
    merge, we would have no one who knew the code enough to merge it
    and take care of merge complications.

  . The bidi branch actually did bitrot, for at least 3 years, until
    yours truly decided it was now or never, and somehow managed to
    find time to do the job.  Knowing now how much effort it took, I
    can assure you that work would never have been done had Stefan and
    Chong not supported me all the way and urged me to merge early.  A
    year from now, I cannot even promise I will have enough time and
    health left to do anything comparable.

> That way finished features like say package support, built-in colour
> theme support, cc-mode and other mode updates, etc., which are less
> invasive, are delivered in a stable release faster.

That's a nice theory, but implementing it in practice needs a much
larger and probably different organization than Emacs development we
have now.  Unlike many other projects, Emacs is a hodgepodge of a
myriad of separate and almost independent subsystems, many of which
require very specific domain knowledge and target different audiences,
sometimes quite narrow ones.  Exposing significant changes to a wide
audience is perhaps the only practical way of testing those changes
efficiently; leaving them on a branch would mean features remain
largely untested (read: buggy) for many months if not years.

If we want to move in the direction of periodical releases, we will
have to come up with a plan that includes organizational and
procedural changes, and we will have to convince ourselves that such a
plan is doable in practice.  First step in the plan should be to bring
much more developers on board.