Re: Feature freezes and Emacs 25

[Eli Zaretskii]

> Date: Tue, 10 Nov 2015 21:25:33 +0800
> From: Xue Fuqiao <address@hidden>
> Cc: Eli Zaretskii <address@hidden>, address@hidden, address@hidden
> 
> I just wrote a draft document for our release process.  Please see the
> attached patches.

Thanks!

> The first patch renamed `admin/FOR-RELEASE' to `admin/RELEASE-PROCESS',

Please grep all the repository for references to FOR-RELEASE.  At
least admin/notes/bugtracker still does.

> 1. Document when to remove obsolete features.  For example, "if a
>    feature is declared obsolete in version `major.minor', it will
>    continue to work in versions `major.minor' and `major+1.minor' but
>    raise warnings, and it will be removed in version `major+2.minor'".
>    I don't think we have a policy for removing obsolete features
>    currently, but IMHO it would be good to have one.

I'm not sure a fixed policy of this kind is possible.  Minor features
can be removed quickly, not-so-minor ones not so quickly.

> 2. Document what to do if a bug needs to be addressed in the next
>    release (a.k.a. release-critical bugs).  For example, how to set the
>    bug meta-data for release-critical bugs, what meta-data to set, the
>    criteria for release-critical bugs, etc.  I didn't write this because
>    I don't know how.  Patches/suggestions are very welcome.

  http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00226.html

> 3. Document the number of pretest and RC releases we need to make for a
>    release, or how to decide the number pretest/RC releases for a
>    release.  I didn't document this because I don't know the policy
>    about this (if any).

There is no policy, and I don't think there could be.  It depends on
the number of bugs reported during the pretest, which in turn depends
on how many radically new features were added.  E.g., Emacs 21.1 had
something like 15 pretests, IIRC.

> * IMHO the current status of Emacs development should be present
>   somewhere, for those who don't follow emacs-devel closely.  Something
>   like this would be a good start:
>   https://wiki.documentfoundation.org/ReleasePlan/5.1#5.1.0_release

That's not status, that's plan.  See the discussion about cadence
model for what I think about that in conjunction with Emacs.

> * I think we need to encourage developers to prioritize bugs during
>   phase two and/or phase three in the release cycle (see my patches for
>   the three phases).  It will make the quality of the new release
>   better, or at least give developers an overview of the general
>   development (bugfix) direction.

Not sure what you mean by "prioritize bugs".  Do you mean priorities
among bugs?  That will only help if there are enough people who work
on fixing bugs, and we want to employ those resources more
efficiently.

> * Currently, the version of an RC release (returned by
>   `(emacs-version)') is the same as a stable release, but as a user,
>   sometimes I can't tell if I'm using a stable version of Emacs or a
>   release candidate.  I still think something like 25.1-rc1 is better
>   than 25.1, because it's clearer.

Actually, we almost never made release candidates.

> [1] My `pre-commit' hook won't let me commit if I don't remove the
> trailing whitespace ;-)

There's the --no-verify switch to "git commit".

> +** Phase two: feature freeze

I think we should discuss this and understand better why this is
needed and what are its entry and exit conditions.

> +Shortly before the feature freeze, Emacs developers will be devoted to
> +figuring out what features to include in the next release and what
> +features to defer to a later release.

If the feature is already on master, we don't have any easy way of
removing it.  Nor should we, IMO.

> +After we cut the release branch, we’ll make pretest and release
> +candidate (RC) releases.  For pretest releases, the "devel" component
> +changes to 90, 91, ...

The number of the first pretest version is not carved in stone.  It
depends on the developers' estimation of how close we are to the
release.  E.g., Emacs 21.1 had its first pretest called 21.0.70,
AFAIR.

Thanks again for working on this.