From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25386 invoked by alias); 12 Nov 2015 19:38:54 -0000 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 Received: (qmail 25017 invoked by uid 89); 12 Nov 2015 19:38:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-HELO: rock.gnat.com Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 12 Nov 2015 19:38:52 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id D60C02997C; Thu, 12 Nov 2015 14:38:50 -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 gV4meeGFwLSs; Thu, 12 Nov 2015 14:38:50 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 980E22997B; Thu, 12 Nov 2015 14:38:50 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 16FB942767; Thu, 12 Nov 2015 11:38:49 -0800 (PST) Date: Thu, 12 Nov 2015 19:38:00 -0000 From: Joel Brobecker To: Sandra Loosemore Cc: Pedro Alves , gdb-patches@sourceware.org Subject: Re: FYI: GDB 7.10.1 release still planned end of Nov Message-ID: <20151112193849.GB4646@adacore.com> References: <20151028164757.GC4009@adacore.com> <5631005E.9070208@redhat.com> <20151112184430.GA4646@adacore.com> <5644E0A4.8020901@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5644E0A4.8020901@codesourcery.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2015-11/txt/msg00281.txt.bz2 > >> [patch] fix misparsing in remote_parse_stop_reply > >> https://sourceware.org/ml/gdb-patches/2015-08/msg00413.html > >> > >>Sandra, could you handle that one? > > > >No answer from Sandra, but I've added it to the the Wiki. > >Sandra - if you want to push it to the branch, remember that > >we need to recreate a PR for it. For now, I've replaced the PR > >numbers by ??? in the GDB 7.10 release wiki page... > > I thought I did respond to this. I'm confused enough by GIT to not know > what the right way to backport a patch from trunk to a release branch is, or > how much re-testing is required, and now I'm even more confused by > "recreating a PR" and the comments about a wiki since I'm not familiar with > GDB's release management processes either. :-S If you can give me more > specific instructions I will help, but maybe it would be just as easy for > someone who knows what they're doing to handle it? I am usually happy doing the grunt work for someone else, but because it doesn't scale, I usually offer it once to each contributor ;-). The reason we need a PR is that it makes documentation of the corrective release a lot easier. Here is how the process works, in a nutshell (this only applies after a first release has been made on a given branch - in other words, it only applies to "corrective" releases): - For a fix that needs to be put on the branch, there must be a PR. If not already existing, then it needs to be created at: https://sourceware.org/bugzilla/ This PR should document in as much details as possible the issue. You can also hyper-link discussions on gdb-patches. This requires an account, but that's trivial to create. - We maintain the list of fixes on the branch via a wiki page. There is one page for each release branch, available from GDB's wiki main page (https://sourceware.org/gdb/wiki/). For the GDB 7.10 release cycle, the wiki page is at: https://sourceware.org/gdb/wiki/GDB_7.10_Release This also requires an account, as well as write privileges, which anyone with write privs (including myself) can give you. But in this case, I've already added the entry in the wiki. I'm just missing the PR number. - Come release time, I copy/paste the list of fixes we pushed to the branch in the announcement. For the news entry on the GDB website, I provide hyperlinks to each PR, so people only have to click on them to access a more comprehensive description of each issue being solved by the corrective release. For the email sent to gdb-announce, it's pure text, but the PR number makes it super easy to locate each PR, and therefore consult it as well. Regarding backporting a change, it's super easy: 1. Find the SHA1 of the fix you pushed to master; I usually use something like "git log --author=[...] --grep=[...] For instance, I did... % git log --author=sandra --grep=strprefix ... and got: commit 26d56a939e9e54e09d46ea6e9678463ac344fa33 Author: Sandra Loosemore Date: Tue Aug 18 10:29:54 2015 -0700 Fix mis-parsing of hex register numbers in 'T' stop replies. 2. Then, create a gdb-7.10-branch branch in your repository: % git branch --track gdb-7.10-branch origin/gdb-7.10-branch You can then cherry-pick the change to that branch: % git checkout gdb-7.10-branch % git cherry-pick 26d56a939e9e54e09d46ea6e9678463ac344fa33 [you will probably need to fix ChangeLog conflicts] And once all is ready, then just push to the FSF repo: % git push origin gdb-7.10-branch -- Joel