gdb-7.11.1 re-spin update

[Joel Brobecker <brobecker at adacore dot com>]

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)

    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 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.
   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.

   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.

   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?

Thanks,
-- 
Joel