Re: Periodical releases

[Carsten Mattner <carstenmattner@googlemail.com>]

On Mon, Jan 2, 2012 at 12:36 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> 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.

okay, this may not work for the current development workflow.

Another proposal:
Don't wait until "perfection" and release trunk more often
with bug releases if needed. Emacs trunk has never been
unstable for me. I'm even using the NS port and it's still
stable.
I would have less of a need to build emacs manually if
there were more release and therefore standard emacs
Linux distros was more up to date.