Re: gdb-7.11.1 re-spin update

[Pedro Alves <palves at redhat dot com>]

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 <process from a container>: 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