From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Feature freezes and Emacs 25 Date: Tue, 10 Nov 2015 19:50:11 +0200 Message-ID: <83y4e5lp64.fsf@gnu.org> References: <56259FDD.8040401@dancol.org> <87zizeme8k.fsf@tromey.com> <5625B166.3080104@dancol.org> <86zizdczhp.fsf@stephe-leake.org> <871tc315y3.fsf@lifelogs.com> <83k2pvqg0l.fsf@gnu.org> <837fluqkd1.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE X-Trace: ger.gmane.org 1447177889 23311 80.91.229.3 (10 Nov 2015 17:51:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Nov 2015 17:51:29 +0000 (UTC) Cc: rgm@gnu.org, nicolas@petton.fr, emacs-devel@gnu.org To: Xue Fuqiao Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Nov 10 18:51:19 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 1ZwD4h-0002Ol-2A for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 18:51:19 +0100 Original-Received: from localhost ([::1]:34583 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwD4g-0003vL-Ch for ged-emacs-devel@m.gmane.org; Tue, 10 Nov 2015 12:51:18 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52677) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwD4R-0003vG-Ch for emacs-devel@gnu.org; Tue, 10 Nov 2015 12:51:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZwD4O-0003KL-5Q for emacs-devel@gnu.org; Tue, 10 Nov 2015 12:51:03 -0500 Original-Received: from mtaout25.012.net.il ([80.179.55.181]:55310) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZwD4N-0003Jv-Od; Tue, 10 Nov 2015 12:51:00 -0500 Original-Received: from conversion-daemon.mtaout25.012.net.il by mtaout25.012.net.il (HyperSendmail v2007.08) id <0NXM00J0016CQA00@mtaout25.012.net.il>; Tue, 10 Nov 2015 19:47:46 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout25.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NXM00EZ21FM2F50@mtaout25.012.net.il>; Tue, 10 Nov 2015 19:47:46 +0200 (IST) In-reply-to: X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.181 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:193898 Archived-At: > Date: Tue, 10 Nov 2015 21:25:33 +0800 > From: Xue Fuqiao > Cc: Eli Zaretskii , nicolas@petton.fr, rgm@gnu.org >=20 > 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-PROCE= SS', 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' b= ut > 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 be= cause > 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 f= or 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. Somet= hing > 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 bett= er > 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 devote= d 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=E2=80=99ll make pretest and re= lease > +candidate (RC) releases. For pretest releases, the "devel" compon= ent > +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.