From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Glenn Morris Newsgroups: gmane.emacs.devel Subject: Re: Feature freezes and Emacs 25 Date: Wed, 11 Nov 2015 14:59:37 -0500 Message-ID: References: <86zizdczhp.fsf@stephe-leake.org> <871tc315y3.fsf@lifelogs.com> <83k2pvqg0l.fsf@gnu.org> <837fluqkd1.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1447272004 20411 80.91.229.3 (11 Nov 2015 20:00:04 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 11 Nov 2015 20:00:04 +0000 (UTC) Cc: Eli Zaretskii , nicolas@petton.fr, Emacs-devel To: Xue Fuqiao Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 11 21:00:02 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZwbYh-0005Dp-P2 for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 20:59:56 +0100 Original-Received: from localhost ([::1]:42704 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwbYh-00047R-SZ for ged-emacs-devel@m.gmane.org; Wed, 11 Nov 2015 14:59:55 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46249) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwbYU-00046H-1d for emacs-devel@gnu.org; Wed, 11 Nov 2015 14:59:44 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwbYS-0001oc-99 for emacs-devel@gnu.org; Wed, 11 Nov 2015 14:59:41 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:59938) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwbYP-0001oC-Uj; Wed, 11 Nov 2015 14:59:38 -0500 Original-Received: from rgm by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1ZwbYP-00065w-Aw; Wed, 11 Nov 2015 14:59:37 -0500 X-Spook: cryptanalysis Wildfire Computer infrastructure CID WMATA X-Ran: &7E"2'Tu?eUu_)Ym,F:y)=_58%%`Uz+'kJT^B7QrnS9[cYMh``*/jp2\SqF+*k:=W8:+sT X-Hue: black X-Attribution: GM In-Reply-To: (Xue Fuqiao's message of "Tue, 10 Nov 2015 21:25:33 +0800") User-Agent: Gnus (www.gnus.org), GNU Emacs (www.gnu.org/software/emacs/) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:194127 Archived-At: 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.