From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16166 invoked by alias); 29 Nov 2012 14:14:25 -0000 Received: (qmail 16136 invoked by uid 22791); 29 Nov 2012 14:14:23 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 29 Nov 2012 14:14:18 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 224A42E352 for ; Thu, 29 Nov 2012 09:14:18 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id mQmFsNpSRjJV for ; Thu, 29 Nov 2012 09:14:18 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id E31062E0AE for ; Thu, 29 Nov 2012 09:14:17 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id E72FEC0359; Thu, 29 Nov 2012 15:14:15 +0100 (CET) Date: Thu, 29 Nov 2012 14:14:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: proposal for branch patches after first release Message-ID: <20121129141415.GJ3540@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00858.txt.bz2 Hello, I would like to propose a change in our procedures when a patch gets checked in a release branch. This would only concern changes that are made after the first release off that branch is made. For instance, once we've made the GDB 7.6 release, any new patch on the gdb_7_6-branch would be affected by this proposal. The problem is the following: - The time it took to assemble the GDB 7.5.1 tarballs, and put them on both sourceware.org and gnu.org was under 30mins. - The amount of time it takes me to write the associated announcement was over 2 hours. The reason for taking this amount of time is that I'd like to tell everyone what it is exactly that 7.5.1 fixes over 7.5. For the first major release (Eg 7.5), I can use the NEWS file, which provides enough information. But for the 7.5.1, I have nothing other than the revision log. So I went through every single commit, and tried to write a small description for each commit (I skipped testsuite changes to save time). The proposal: Once a release has been published off a branch, any patch merged on the release branch requires a corresponding update in the NEWS file. I think that it makes sense regardless of the problem that affects me because, if someone feels strongly enough that the problem should be fixed in a subsequent corrective release, I think it deserves a NEWS entry. Also, it will allow users to refer to the NEWS files to determine what exactly the corrective release fixes. And it will save me tons of time because I can now write the annoucement using the information there. Technically, I think we'll want the NEWS update to be checked in both HEAD + branch. But I don't think we can add the entries in the HEAD branch right away, because we don't know ahead of time whether a corrective release will be made or not. So what I propose is the following: The NEWS entry should be checked in the branch. And the Release Manager (me) will add those entries to the HEAD when publishing the new release. OK? -- Joel