From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel,gmane.mail.mh-e.devel Subject: Re: Continued development during release process Date: Sat, 22 Apr 2006 13:35:56 +0300 Message-ID: References: <2167.1145655433@olgas.newt.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: main.gmane.org X-Trace: sea.gmane.org 1145702184 29348 80.91.229.2 (22 Apr 2006 10:36:24 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 22 Apr 2006 10:36:24 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Apr 22 12:36:20 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FXFTP-0005jn-IA for ged-emacs-devel@m.gmane.org; Sat, 22 Apr 2006 12:36:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FXFTP-0003AP-2f for ged-emacs-devel@m.gmane.org; Sat, 22 Apr 2006 06:36:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FXFTC-0003AJ-Ko for emacs-devel@gnu.org; Sat, 22 Apr 2006 06:36:06 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FXFTB-0003A6-QG for emacs-devel@gnu.org; Sat, 22 Apr 2006 06:36:06 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FXFTB-0003A3-HD for emacs-devel@gnu.org; Sat, 22 Apr 2006 06:36:05 -0400 Original-Received: from [192.114.186.20] (helo=nitzan.inter.net.il) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FXFUw-0001Nk-B3 for emacs-devel@gnu.org; Sat, 22 Apr 2006 06:37:54 -0400 Original-Received: from HOME-C4E4A596F7 (IGLD-83-130-212-1.inter.net.il [83.130.212.1]) by nitzan.inter.net.il (MOS 3.7.3-GA) with ESMTP id DEJ05805 (AUTH halo1); Sat, 22 Apr 2006 13:35:55 +0300 (IDT) Original-To: emacs-devel@gnu.org, mh-e-devel@lists.sourceforge.net In-reply-to: <2167.1145655433@olgas.newt.com> (message from Bill Wohler on Fri, 21 Apr 2006 14:37:13 -0700) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:53225 gmane.mail.mh-e.devel:12154 Archived-At: > Date: Fri, 21 Apr 2006 14:37:13 -0700 > From: Bill Wohler > Cc: mh-e-devel@lists.sourceforge.net > > First of all, if you're handling the release, including tagging and > stuff, please let me know who you are. That's not me, and AFAIK no one has stepped forward to volunteer for the job yet. > Second, once you add a pretest tag, will you make subsequent tags based > upon that tag, or will you simply tag the trunk? I don't really understand the question, so maybe what's below won't answer it; sorry. When the pretest is under way, at some point a release-candidate branch is created. (I say ``at some point'' because I don't think there's an agreement whether this should happen right away when the pretest starts, or later, much closer to the release itself, i.e. at pretest end.) This branch is used for the initial release, in this case for version 22.1, and for all subsequent bug-fix releases that (at least ideally) fix bugs without introducing major features; these would be versions 22.2, 22.3, etc., until it is decided by The Powers That Be that it's time to make another release from the trunk. If the release branch is _not_ cut as soon as the pretest starts, the trunk is frozen for anything but bugfixes from the pretest start and until we branch. As soon as the branch _is_ cut, it is possible to resume development commits to the trunk, in parallel with fixing bugs on the release branch. (One of the arguments _against_ branching early is that, given the relatively small number of core developers, opening the trunk for development might leave too few people to actively work on fixing bugs on the branch.) Having said that, a caveat: the above is based on my limited experience with one of the 21.x releases. That was a long time ago, so it's possible that for the upcoming release the procedures will be different. AFAIK, this was never seriously discussed, because doing so far from the pretest is a largely academic dispute. In any case, whoever volunteers for the job will have an important say on how the release process is managed. HTH