Re: Feature freezes and Emacs 25

[Glenn Morris]

Xue Fuqiao wrote:

> I just wrote a draft document for our release process.  Please see the
> attached patches.  I'm not quite familiar with the release process
> either, and the process was written merely by impression.  I think
> Nicolas and Glenn are more familiar with the release process, so I just
> added them to the Cc list.  Comments are warmly welcomed.

I haven't read the draft, so the following comments are only on your email.

> The first patch renamed `admin/FOR-RELEASE' to `admin/RELEASE-PROCESS',
> and removed the trailing whitespace[1].

Does the (long-standing) name of the file really make a difference to anything?
If you are going to rename it, you don't have to stick with an
old-school SHOUTY name, you can use lower-case.


In the following, there is no existing policy in many cases.
IMO trying to document existing policy and create policy should be
separate activities. Also I would resist the temptation to have a policy
for _everything_.

> 1. Document when to remove obsolete features.

There's no existing policy, and this seems separate from making releases?
The unofficial one is something like "there should normally be at least
one major release between making something obsolete and removing it".
(Personally I go with two.)

> 2. Document what to do if a bug needs to be addressed in the next
>    release (a.k.a. release-critical bugs). 

Fix it?

>  For example, how to set the bug meta-data for release-critical bugs,
>  what meta-data to set,

In the past we increased the severity of such bugs.
Personally I felt this was a bad idea,

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

so I unilaterally started using "block" for this.
That thread explains how it works.

No one else has shown any interest in tracking such things AFAIK.

> 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.

The "policy" is that there are as many pretests as needed until the code
is of sufficient quality to release. A new pretest is made whenever
there have been sufficient changes from the last one to warrant it.

Normally, there is one RC, unless an unexpected last-minute problem occurs.

> 4. Document how to coordinate with the release schedule of packages like
>    Org and Gnus.

There is no policy. Personally I don't think one is needed.

> 5. Add information about uploading the Windows binary to
>    https://ftp.gnu.org/gnu/emacs/windows/, in `admin/make-tarball.txt'.

In exactly the same way anything else is uploaded to ftp.gnu.org?

> 6. Document the criteria for feature freeze, i.e., when should we freeze
>    the master branch?

This is up the lead maintainer(s).

> 7. Things related to people.  Such as:
>    * Who is in charge of a release?

Whoever the lead maintainer(s) says is.

>    * Who may make a good candidate for an RM (release manager)?

The one person who volunteers?

Sorry, I'm more cynical than you! :)

> * 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.

Obviously we've always tried to do that. Good luck!

> * 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.

The whole point of an RC is that the tarfile is literally identical to
the release. If all goes as planned, it IS the release. Therefore it has
to have the same version number. Otherwise it's just another pretest.
Personally I have never found this a source of confusion.