From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20877 invoked by alias); 29 Nov 2012 21:04:58 -0000 Received: (qmail 20866 invoked by uid 22791); 29 Nov 2012 21:04:57 -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 21:04:50 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 2710D2E29B; Thu, 29 Nov 2012 16:04:49 -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 03yChVedJ9Z7; Thu, 29 Nov 2012 16:04:49 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 56BE52E276; Thu, 29 Nov 2012 16:04:48 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id C53DDC0359; Thu, 29 Nov 2012 22:04:40 +0100 (CET) Date: Thu, 29 Nov 2012 21:04:00 -0000 From: Joel Brobecker To: Pedro Alves Cc: Eli Zaretskii , gdb-patches@sourceware.org Subject: Re: proposal for branch patches after first release Message-ID: <20121129210440.GL3581@adacore.com> References: <20121129141415.GJ3540@adacore.com> <83wqx4v12l.fsf@gnu.org> <50B78E0C.50607@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50B78E0C.50607@redhat.com> 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/msg00900.txt.bz2 > > That'd be a nuisance, IMO, because some of them might be > > NEWS-unworthy. > > I agree. And this results in a bit awkward NEWS file, in that we don't > normally document bug fixes there, but point releases are usually > only about bug fixes. I agree it'd be pushing it for some commits (but I thought it'd still be OK). Let's put that idea aside for now. > > An alternative would be to require some predictably formatted string > > in the log entry or the commit message, which you then could grep for. > A one line at the head would be quite standard, given people have come > used to mail subject == git commit summary. This might be the easiest, > though making this a "branch-only" requirement is very error prone. > > I wouldn't mind at all enforcing better and more self-contained commit > log style, FWIW. While I agree it's a good idea to move towards this principle, and for both head & branch, I think there is too much of a chance for oversights. > We could also make better use of bugzilla for this. I had stated my opinion > on this : [...] > If people think the PR idea is too process burden for mainline, we could > require this only for fixes that go into a release branch. E.g., tag > the PRs with a special tag, e.g. "in-7.6.1". Some of the commits in this release in fact did have a PR number, and I was sometimes able to use that. But I noticed two issues: 1. It takes time to process each commit, and then go through the various messages in the PR. 2. Often, I will still have to look into the code itself to really figure out what the problem is. Take for instance PR gdb/14494 (http://sourceware.org/bugzilla/show_bug.cgi?id=14494). How do I quickly write up a description of the problem actually fixed? I also think that having the information spread out, be it in the revision logs, or in a bugs database, makes it hard for anyone who wants to figure out what changes exactly a minor release contains and for what purpose. For all these reasons, I think that having the developer write up the description himself, with approval from Eli, and put it somewhere in a file, would be best. If we want to call it known-problems or anything else, instead of putting that info in the NEWS files, that would be fine as well. -- Joel