From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27564 invoked by alias); 3 Dec 2012 06:51:47 -0000 Received: (qmail 27551 invoked by uid 22791); 3 Dec 2012 06:51:46 -0000 X-SWARE-Spam-Status: No, hits=-5.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail-ob0-f169.google.com (HELO mail-ob0-f169.google.com) (209.85.214.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Dec 2012 06:51:36 +0000 Received: by mail-ob0-f169.google.com with SMTP id lz20so2453412obb.0 for ; Sun, 02 Dec 2012 22:51:35 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=EJeoekGqa7w/2YrhF5kr+qSuNvoRd0flPpw8n+OdjIo=; b=HDAnbaB3K7AE/nuRB+/sbP2K82TuDfaMl5MerejvNuKPqjTCf8SAxgYcTr806Dcs6h Ns5sAk3F1vTl/64BmdZq4kfxFeEyZDKsjUBTwHGu2v6SYfEXwZ6eB14casF27xqwNhPq bJE1G1gpVmKSP4HGImlxgExvOSSvM9969b4Nhdu0vWo33zrUd/UpHlDBuojM6ZKp8YX6 5fh+YJynWmZjuc13b6rlyLdVUP03zOX+W9w3PUmTf3oZBTqLLjWvLHCoEKifmNpld0If 6kRJat0QhtoZgP4xAtmabbupr90IK6BKZ1xqULoEMnTAT988R5Qy84AVox6Uf1MqCVnu pMkg== MIME-Version: 1.0 Received: by 10.60.154.169 with SMTP id vp9mr7190355oeb.109.1354517495783; Sun, 02 Dec 2012 22:51:35 -0800 (PST) Received: by 10.76.1.197 with HTTP; Sun, 2 Dec 2012 22:51:35 -0800 (PST) In-Reply-To: <20121129141415.GJ3540@adacore.com> References: <20121129141415.GJ3540@adacore.com> Date: Mon, 03 Dec 2012 06:51:00 -0000 Message-ID: Subject: Re: proposal for branch patches after first release From: Doug Evans To: Joel Brobecker Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQmMYm13YfZCxvheOp5JzCxsUdivMI25usPL7Z36Wit/85cGbKREajPyTRbeOIn0cbaa16tTmzd/ZeoKYUUC5nUwzDXmlZ6snoouYejZqzKgD5UKd6T/7Yg8djsrGlprXdt64XfCYveRTtlFCrPNJ+XrlwCYdVX5V7hFiabecNx8eBbBFZkZKKINAFH95jNuhmyToNnRwAbHunffpbXUhcPBdh9Yyw== X-IsSubscribed: yes 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-12/txt/msg00014.txt.bz2 On Thu, Nov 29, 2012 at 6:14 AM, Joel Brobecker wrote: > 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. If it were me I'd just diff the ChangeLogs, write something based on that (but not worry about being too detailed if it'll take too much time to dig deeper), require bug numbers or whatever to be in the ChangeLogs, and leave it at that.