[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Periodical releases
From: |
Eli Zaretskii |
Subject: |
Re: Periodical releases |
Date: |
Mon, 02 Jan 2012 06:36:16 -0500 |
> 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.
- Re: Periodical releases, Stefan Monnier, 2012/01/01
- Re: Periodical releases, Carsten Mattner, 2012/01/02
- Re: Periodical releases,
Eli Zaretskii <=
- Re: Periodical releases, Carsten Mattner, 2012/01/02
- Re: Periodical releases, Eli Zaretskii, 2012/01/02
- RE: Periodical releases, Drew Adams, 2012/01/02
- Re: Periodical releases, chad, 2012/01/02
- Re: Periodical releases, Carsten Mattner, 2012/01/02
- Re: Periodical releases, Eric Schulte, 2012/01/02
- Re: Periodical releases, Carsten Mattner, 2012/01/02
- Re: Periodical releases, LluĂs, 2012/01/02
- Re: Periodical releases, Carsten Mattner, 2012/01/02
- RE: Periodical releases, Drew Adams, 2012/01/02