[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Periodical releases

From: Carsten Mattner
Subject: Re: Periodical releases
Date: Mon, 2 Jan 2012 13:57:50 +0100

On Mon, Jan 2, 2012 at 12:36 PM, Eli Zaretskii <address@hidden> wrote:
>> Date: Mon, 2 Jan 2012 11:40:20 +0100
>> From: Carsten Mattner <address@hidden>
>> Cc: Emacs developers <address@hidden>
>> > 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
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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]