From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sourceware.org
Subject: gdb-7.11.1 re-spin update
Date: Mon, 25 Apr 2016 21:50:00 -0000 [thread overview]
Message-ID: <20160425214951.GA4079@adacore.com> (raw)
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
next reply other threads:[~2016-04-25 21:50 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-25 21:50 Joel Brobecker [this message]
2016-04-26 12:16 ` Pedro Alves
2016-05-02 15:46 ` Joel Brobecker
2016-05-02 17:23 ` Pedro Alves
2016-05-02 19:38 ` Joel Brobecker
2016-05-02 19:41 ` Pedro Alves
2016-05-02 21:16 ` Joel Brobecker
2016-05-02 21:30 ` Pedro Alves
2016-05-05 13:49 ` Joel Brobecker
2016-04-27 19:36 ` Jan Kratochvil
2016-05-03 14:19 ` Simon Marchi
2016-05-03 14:31 ` Joseph Myers
2016-05-03 15:01 ` Simon Marchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160425214951.GA4079@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox