Re: Feature freezes and Emacs 25

[Xue Fuqiao <xfq.free@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4351 bytes --]

On Wed, Nov 11, 2015 at 1:50 AM, Eli Zaretskii <eliz@gnu.org> wrote:

Hi Eli,

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

Fixed, thanks.

I removed the reference to FOR-RELEASE in admin/notes/bugtracker,
because I think all bugs found should be in the bug tracker, instead of
having some of them in the RELEASE-PROCESS file.

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

OK.

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

Thanks.  I've made some changes about this in the new patch (attached).
Furthermore, I hope we can get rid of the BUGS section in
RELEASE-PROCESS and move it entirely to Debbugs.

(BTW, I hope we can file a meta-bug, listing all release-tracking bugs
like #19758 and #19759, and update it in each release, so that we don't
have to update the RELEASE-CRITICAL BUGS section in every future
release, and we can see our previous release-tracking bugs more
conveniently.)

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

OK, I'll see.

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

I mean, adding severity level for bugs and adding blocking bugs.  So
the chance of important bugs missed in the new release will be reduced.
This needs to be done in every phase, but is even more important in the
bugfix phase.

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

Thanks for the hint Eli - you are right as usual.

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

I agree.  John (and others)?  Any comment on this?

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

That's not what I meant.  I meant the long-term feature branches
(concurrency/dynamic-modules/xwidget), and features still under
discussion (xref/project?).

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

But IMHO having a consistent versioning scheme for pretests should
better in the future.  The estimation is somewhat subjective.

Thanks for your review!

[-- Attachment #2: 0002-Document-the-release-process.patch --]
[-- Type: application/octet-stream, Size: 6437 bytes --]

From 43f3db250aeea5c81556f7f624dcab87889c20e5 Mon Sep 17 00:00:00 2001
From: Xue Fuqiao <xfq.free@gmail.com>
Date: Tue, 10 Nov 2015 17:46:51 +0800
Subject: [PATCH 2/2] Document the release process

* admin/notes/versioning: Add information about RC releases.

* admin/RELEASE-PROCESS: Document the release process.

* admin/authors.el (authors-ignored-files):
* admin/README:
* CONTRIBUTE: Change FOR-RELEASE to RELEASE-PROCESS.
---
 CONTRIBUTE             |  2 +-
 admin/README           |  4 ++--
 admin/RELEASE-PROCESS  | 58 +++++++++++++++++++++++++++++++++++++++++++++++++-
 admin/authors.el       |  2 +-
 admin/notes/bugtracker |  3 +--
 admin/notes/versioning | 11 ++++++----
 6 files changed, 69 insertions(+), 11 deletions(-)

diff --git a/CONTRIBUTE b/CONTRIBUTE
index 0ca5d0d..db1e35c 100644
--- a/CONTRIBUTE
+++ b/CONTRIBUTE
@@ -145,7 +145,7 @@ messages:
   will suffice.
 
 - There is no need to mention files such as NEWS, MAINTAINERS, and
-  FOR-RELEASE, or to indicate regeneration of files such as
+  RELEASE-PROCESS, or to indicate regeneration of files such as
   'configure', in the ChangeLog entry.  "There is no need" means you
   don't have to, but you can if you want to.
 
diff --git a/admin/README b/admin/README
index 2286e35..22c72f4 100644
--- a/admin/README
+++ b/admin/README
@@ -12,9 +12,9 @@ what you do when using them.
 
 * Instructions and scripts used to prepare an Emacs release.
 
-** FOR-RELEASE
+** RELEASE-PROCESS
 
-Living list of activities that must be completed before the next release.
+The release process used by GNU Emacs.
 
 ** make-tarball.txt
 
diff --git a/admin/RELEASE-PROCESS b/admin/RELEASE-PROCESS
index 286b90e..cf59184 100644
--- a/admin/RELEASE-PROCESS
+++ b/admin/RELEASE-PROCESS
@@ -1,7 +1,56 @@
-Tasks needed before the next release.
+This document describes the release process used by GNU Emacs.
+
+* RELEASE CYCLE
+
+Each release cycle will be split into three periods.
+
+** Phase one: development
+
+The first phase of the release schedule is the "heads-down" working
+period for new features.
+
+** Phase two: feature freeze
+
+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.
+
+During the feature freeze, no new features will be accepted in
+`master'.  It ensures that sufficient share of the release cycle is
+dedicated to QA.
+
+When the feature freeze is over, a release branch called "emacs-NN"
+("NN" represents the major version number of the new Emacs release)
+will be cut from `master'.
+
+** Phase three: bugfixes
+
+The last phase of a release cycle is spent fixing bugs and eliminating
+undocumented new features on the "emacs-NN" branch.
+
+In parallel to this phase, `master' can receive new features, to be
+released in the next release cycle.  From time to time, the master
+branches merges bugfix commits from the "emacs-NN" branch.
+
+* RELEASE-CRITICAL BUGS
+
+Emacs uses the "blocking bug(s)" feature of Debbugs for bugs need to
+be addressed in the next release.
+
+Currently, bug#19759 is the tracking bug for release of 25.1.  Say
+bug#123 needs to be fixed for Emacs 25.1.  Send a message to
+control@debbugs.gnu.org that says:
+
+   block 19759 by 123
+
+Change "block" to "unblock" to unblock the bug.
 
 * TO BE DONE SHORTLY BEFORE RELEASE
 
+** Make sure the Copyright date reflects the current year in the source
+files.  See `admin/notes/years' for information about maintaining
+copyright years for GNU Emacs.
+
 ** Make sure the necessary sources and scripts for any generated files
 are included in the source tarfile.  (They don't need to be installed,
 so eg admin/ is fine.)
@@ -275,6 +324,13 @@ tips.texi
 variables.texi
 windows.texi
 
+* OTHER INFORMATION
+
+For Emacs's versioning scheme, see `admin/notes/versioning'.
+
+For instructions to create pretest or release tarballs, announcements,
+etc., see `admin/make-tarball.txt'.
+
 \f
 Local variables:
 mode: outline
diff --git a/admin/authors.el b/admin/authors.el
index 3d7850a..f5d23be 100644
--- a/admin/authors.el
+++ b/admin/authors.el
@@ -267,7 +267,7 @@ authors-ignored-files
   '("external-lisp"
     "lock" "share-lib" "local-lisp"
     "noleim-Makefile.in"
-    "NEWS" "ORDERS" "PROBLEMS" "FAQ" "AUTHORS" "FOR-RELEASE" "TODO" "todo"
+    "NEWS" "ORDERS" "PROBLEMS" "FAQ" "AUTHORS" "RELEASE-PROCESS" "TODO" "todo"
     "MACHINES" "SERVICE"
     "README.unicode" "README.multi-tty" "TUTORIAL.translators"
     "NEWS.unicode" "COPYING.DJ" "Makefile.old" "Makefile.am"
diff --git a/admin/notes/bugtracker b/admin/notes/bugtracker
index fb65bbe..3d6df03 100644
--- a/admin/notes/bugtracker
+++ b/admin/notes/bugtracker
@@ -140,8 +140,7 @@ you can add an element to gnus-posting-styles to do this automatically, eg:
 
 ** To record a bug in the tracker without sending mail to the bug list.
 This can be useful to make a note of something discussed on
-emacs-devel that needs fixing.  In other words, this can be the
-equivalent of adding something to FOR-RELEASE.
+emacs-devel that needs fixing.
 
 To: quiet@debbugs.gnu.org
 [headers end]
diff --git a/admin/notes/versioning b/admin/notes/versioning
index e422b22..e956a68 100644
--- a/admin/notes/versioning
+++ b/admin/notes/versioning
@@ -9,16 +9,19 @@ Emacs version numbers have the form
 "build" increments each time Emacs is built in the same location
 (without cleaning) and isn't really part of the version.
 
-bugfix releases increase "minor" by 1.
-non-bugfix releases increase "major" by 1, and reset "minor" to 1.
+Bugfix releases increase "minor" by 1.
+Non-bugfix releases increase "major" by 1, and reset "minor" to 1.
 (The division between bugfix and non-bugfix has not always been clear
 historically.)
 
 Unreleased (development) versions have an extra "devel" component.
 This is a fairly meaningless number that may be unchanged for a long time.
 It is normally 50.
-When the release process starts, it changes to 90, 91, ...
-When the actual release is made, this component is removed.
+
+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, ...  When the first RC release is made, this
+component is removed.
 
 The development version for a new major release has "minor" = 0.
 The development version for a new minor release has "minor" = that of
-- 
2.6.3