From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8429 invoked by alias); 26 Apr 2016 12:16:05 -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 8400 invoked by uid 89); 26 Apr 2016 12:16:05 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=faith, progressed, heads, reservations X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 26 Apr 2016 12:15:54 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 95F7F3B731; Tue, 26 Apr 2016 12:15:53 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u3QCFq4b012079; Tue, 26 Apr 2016 08:15:52 -0400 Subject: Re: gdb-7.11.1 re-spin update To: Joel Brobecker , gdb-patches@sourceware.org References: <20160425214951.GA4079@adacore.com> From: Pedro Alves Message-ID: <571F5BF8.4090205@redhat.com> Date: Tue, 26 Apr 2016 12:16:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160425214951.GA4079@adacore.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2016-04/txt/msg00550.txt.bz2 On 04/25/2016 10:49 PM, Joel Brobecker wrote: > Hello, > > It's been 2 months since 7.11 was released. If all goes well, > we're therefore about 1 month away from the 7.11.1 release. > So I thought I'd send a quick heads up as well as try to get > a status update. > > Looking at the wiki page for that release branch > (https://sourceware.org/gdb/wiki/GDB_7.11_Release), I see > there are currently 2 items marked critical before 7.11.1 > can be released: > > PR gdb/19828 > (7.11 regression: non-stop gdb -p : internal error) I've assigned myself not. I have a patch for this, but it surprisingly causes regressions in the attach-many-short-lived-threads.exp testcase. I need to find some more time to stare at "set debug infrun" logs and fully understand why. > > PR remote/19863 > (7.10 regression: gdb remote.c due to "setfs" with gdbserver <=7.9) > > We are missing an assignee (someone willing to take charge of getting > a fix in) for both issues. Is anyone working on either of these? > If you are, can you please add your name ahead of the relevant > entries? > > Also, quick procedural question: > > I notice that the "Done" list has some items explicitly listed, > and then a generic item giving a link to bugzilla for all bugs > identified for 7.11.1, or else fixed for 7.11.1. I was the one who first added these urls, sorry if it causes you trouble, and sorry that I didn't reach out to you before actually doing it. I thought in good faith that that would be an obvious improvement. Let me explain what went through my mind: I think I first added the bugzilla query url as convenience for the 7.11 release. Having a convenient url there would made it easier to at any time see if we still had bugs open against 7.11, and reevaluate if any are blockers. I find it easier to go through gdb-prs@ mailing list traffic each day, triaging bugs, and if a bug is identified as regression, mark it with "milestone == 7.11", and move one to the next bug. Having to edit the wiki in addition just feels like unnecessary process while doing this. I then did the same for the 7.11.1 release section, but this time rather than just the open bugs url, I added the "fixed bugs" search url too, as without that whenever you close the bug you'd still have to manually list it in the wiki. I guess it just sort of naturally progressed in that direction. At the same time, I found it a bit annoying before that I had to request from people that want to backport patches to the branch that they need to: #1 - create bugzilla bug #2 - do actual backporting #3 - add entry to wiki We already have lots of heavy processes in place, and it felt a bit cumbersome to ask for #3 when the person doing the backport may not even have a wiki account. While I can obviously volunteer to do the wiki editing myself, it's also time that I could be spending elsewhere too. So I thought, that given that bugzilla knows to give us bug lists, and we already have the milestone field, why not just centralize bug status handling in bugzilla, while leaving the listing of non-bug issues that may block the release in the wiki. > > I could conceive of using this kind of generic link for bugs > identified as critical for 7.11, provided that we make sure that > these bugs are always assigned to someone. Otherwise, we cannot > know who to contact for an update when we get closer to the release. It's the same with the list in the wiki page though. > That being said, I have some reservations about this, because > it is harder to make sure that whoever sets the target milestones > does so after having consulted the group about it. Personally, > I would prefer that we explicitly list each item in the wiki's > TODO, because anyone can subscribe to updates here, and make sure > that these updates were agreed upon before being added. Not sure I understand what you mean. I assume maintainers are all following / tracking the gdb-prs@ list, where such changes can be seen. We can just as well discuss before adding a milestone marker to bugzilla, both in the bug itself, and here. OTOH, it's likewise possible to add things to the wiki page without discussion first, which actually I think is what normally happens. > For the "Done" section, on the other hand, using the generic > link is a bit of a regression for me. Now, instead of copy/pasting > one list (into the news webpage, and then the announcement email), > I now have to copy/paste one list, then go to bugzilla and then > massage another list into looking like the first one, so I can append > that list too. > > I understand that this is easier for everyone but me; I am > wondering if we could share a bit the work. It's a minute here > and there for each one of us, so that I don't have to spend > that minute times the number of fixes when I work on the release > announcement. I imagined it would only take a few seconds to do, as the bugzilla url already puts the bug number and subject in the same line. Are you perhaps seeing something else beyond the formatting? Bad bug subjects, perhaps? > > If you guys agree, I think what we can do is move the URL to > the open bugs in bugzilla to an FYI section so we remember to > review that list before actually starting the release process. > But we'd then avoid those for the TODO and Done sections, > explicitly listing each item in the wiki page instead. > > Would that be OK? I'll be OK with whatever you prefer, really. Thanks, Pedro Alves