Re: Feature freezes and Emacs 25

[Xue Fuqiao]

>>> Actually, I think we should document our release process more
>>> explicitly.  `admin/FOR-RELEASE' and `admin/notes/versioning' are not
>>> enough.
>>
>> I agree. Would you be willing to contribute some drafting? I myself am still
>> unfamiliar with all of our procedures in this regard.

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.

The first patch renamed `admin/FOR-RELEASE' to `admin/RELEASE-PROCESS',
and removed the trailing whitespace[1].  The second patch documents the
release process in `admin/RELEASE-PROCESS'.

There are things I would like to write, but didn't write for various
reasons:

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.

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.

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

4. Document how to coordinate with the release schedule of packages like
   Org and Gnus.  I didn't write this because I'm not familiar with the
   process.  Again, patches/suggestions are very welcome.

5. Add information about uploading the Windows binary to
   https://ftp.gnu.org/gnu/emacs/windows/, in `admin/make-tarball.txt'.
   I didn't write this because I'm not familiar with the process.
   Patches are welcome.

6. Document the criteria for feature freeze, i.e., when should we freeze
   the master branch?  I didn't write this because we don't have a
   policy for this currently.

7. Things related to people.  Such as:
   * Who is in charge of a release?
   * Who may make a good candidate for an RM (release manager)?

In addition, I have some suggestions about our current release process
and versioning scheme:

* 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

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

* 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 release process I wrote applies mainly to a new major release (such
as 25.1) instead of a minor release (such as 24.5).  So the documents
still need expanding.  Comments?

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

0001-admin-RELEASE-PROCESS-Rename-from-admin-FOR-RELEASE.patch
Description: Binary data

0002-Document-the-release-process.patch
Description: Binary data