gdb-7.11.1 re-spin update

gdb-7.11.1 re-spin update

[Joel Brobecker]

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

Re: gdb-7.11.1 re-spin update

[Pedro Alves]

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

Re: gdb-7.11.1 re-spin update

[Jan Kratochvil]

On Mon, 25 Apr 2016 23:49:51 +0200, Joel Brobecker wrote:
> 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 remote/19863
>     (7.10 regression: gdb remote.c due to "setfs" with gdbserver <=7.9)

I have checked in master + 7.11 branch and closed this PR now.


Jan

Re: gdb-7.11.1 re-spin update

[Joel Brobecker]

Hi Pedro,

Sorry I wasn't able to anwer this any sooner...

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

It makes sense.

On the other hand, the first advantage of having it in the wiki was
that I was able to subscribe to the release wiki page, and therefore
get an email each time a chnage in made. The side effect of that I can
then double-check the entries added, and in particular checking that
someone is assigned that entry.

If there is a way for me to subscribe to all bugzilla PRs that get
assigned a specific release version, then the downside of using
bugzilla only is less. I might still have to open the bugzilla PR
to verify that the PR is assigned to someone, but given the number
of such PRs, I can live with that. But the question is - can we
subscribe to a category or all of bugzilla?

Otherwise, if someone is already tracking bugzilla PRs and also
understands the release process, I am fine delegating this part
of the work.  One of the important aspects of that is making sure
that the information remains accurate, at least up to release;
so that the release announcement is as correct as can be.

WDYT?

-- 
Joel

Re: gdb-7.11.1 re-spin update

[Pedro Alves]

On 05/02/2016 04:46 PM, Joel Brobecker wrote:

> If there is a way for me to subscribe to all bugzilla PRs that get
> assigned a specific release version, then the downside of using
> bugzilla only is less. I might still have to open the bugzilla PR
> to verify that the PR is assigned to someone, but given the number
> of such PRs, I can live with that. But the question is - can we
> subscribe to a category or all of bugzilla?

Bugzilla supports sending notifications when the milestone changes,
(it's in the preferences page), but I don't how to do that when
you're not the assignee/reporterd/cced to the bug.

What I do, is subscribe to the gdb-prs mailing list:

 https://sourceware.org/ml/gdb-prs/

so I get a message for _every_ change done on our bugzilla.

I follow this list like I follow gdb-patches@.  I have a mail
filter that puts all gdb-prs traffic on its own mail/imap dir.

(Note one can reply to these bugzilla email via email too, which
is convenient at times.)

For example, I just now changed the milestone of PR build/20029
to 7.11.1, and that generated this mail:

 https://sourceware.org/ml/gdb-prs/2016-q2/msg00171.html

( and just using the bugzilla interface for that was quite
 convenient.  :-) )

Guess if one wanted, one could easily set up a mail filter
based on "List-id: gdb-prs" and the "Target Milestone" string
being present in the mail body.


> Otherwise, if someone is already tracking bugzilla PRs and also
> understands the release process, I am fine delegating this part
> of the work.  

At least I track bugzilla PRs.  I had assumed all maintainers did.
I don't reply to all PRs, there's just not enough time
unfortunately, but at least I read all and have been trying to
make sure milestones are set.

> One of the important aspects of that is making sure
> that the information remains accurate, at least up to release;
> so that the release announcement is as correct as can be.

Given that the entries in the wiki page are just the
PR title, I think that ends up being the same amount or even
less work.  If a bug has an incomplete or inaccurate title,
we should just fix it on the bug directly, IMO.

Thanks,
Pedro Alves

Re: gdb-7.11.1 re-spin update

[Joel Brobecker]

> What I do, is subscribe to the gdb-prs mailing list:
> 
>  https://sourceware.org/ml/gdb-prs/
> 
> so I get a message for _every_ change done on our bugzilla.

I could do that, and filter on any of:

    X-Bugzilla-Changed-Fields: cc target_milestone
    X-Bugzilla-Target-Milestone:

The summary provides the assignee, so I think I think we can try that
for this release. If it works well, I suggest we completely switch
over to a bugzilla-only approach starting with the following release.

It looks like https://sourceware.org/bugzilla/show_bug.cgi?id=20029
had its target milestone set to 7.11.1 by the reporter (nightstrike).
That's one of the things I'd like to catch, just to make sure things
get discussed.  It should be fairly easy to fix that one, especiallyi
you posted a link to a patch pending review. But if the patch doesn't
make it, I think we can release without it, since warnings on the branch
are not fatal.

-- 
Joel

Re: gdb-7.11.1 re-spin update

[Pedro Alves]

On 05/02/2016 08:38 PM, Joel Brobecker wrote:

> It looks like https://sourceware.org/bugzilla/show_bug.cgi?id=20029
> had its target milestone set to 7.11.1 by the reporter (nightstrike).

That was actually me.  You can tell from:

Pedro Alves <palves at redhat dot com> changed:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
(...)
   Target Milestone|---                         |7.11.1


> That's one of the things I'd like to catch, just to make sure things
> get discussed.  It should be fairly easy to fix that one, especiallyi
> you posted a link to a patch pending review. But if the patch doesn't
> make it, I think we can release without it, since warnings on the branch
> are not fatal.

Ah, indeed, I had forgotten that warnings are not fatal.

Thanks,
Pedro Alves

Re: gdb-7.11.1 re-spin update

[Joel Brobecker]

> > It looks like https://sourceware.org/bugzilla/show_bug.cgi?id=20029
> > had its target milestone set to 7.11.1 by the reporter (nightstrike).
> 
> That was actually me.  You can tell from:
> 
> Pedro Alves <palves at redhat dot com> changed:
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> (...)
>    Target Milestone|---                         |7.11.1

Is that from the email sent to gdb-prs? I was looking for this info
in the PR's log, and couldn't find that information. Not a problem,
though, since the wiki wouldn't be doing any better in this area...

-- 
Joel

Re: gdb-7.11.1 re-spin update

[Pedro Alves]

On 05/02/2016 10:16 PM, Joel Brobecker wrote:
>>> It looks like https://sourceware.org/bugzilla/show_bug.cgi?id=20029
>>> had its target milestone set to 7.11.1 by the reporter (nightstrike).
>>
>> That was actually me.  You can tell from:
>>
>> Pedro Alves <palves at redhat dot com> changed:
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> (...)
>>    Target Milestone|---                         |7.11.1
> 
> Is that from the email sent to gdb-prs?

Yes, from:

 https://sourceware.org/ml/gdb-prs/2016-q2/msg00171.html

(Actually, the "From:" field also mentions my account.)

> I was looking for this info
> in the PR's log, and couldn't find that information. 

Yeah.  I don't know how to get that info out of bugzilla directly.

> Not a problem,
> > though, since the wiki wouldn't be doing any better in this area...

Yeah, it's at least archived in the gdb-prs mailing list archive.

Thanks,
Pedro Alves

Re: gdb-7.11.1 re-spin update

[Simon Marchi]

On 16-04-25 05:49 PM, Joel Brobecker wrote:
>    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 think that this particular problem could be efficiently solved with scripting.
Apparently, Bugzilla now has an API [1], although I can't find how to use it on
the sourceware BZ, maybe it's too old.

If that API was accessible, it should be easy to write a script that prints a
nicely formatted list of all issues with target milestone == 7.11.1, ready to
copy paste in the email.  It could also tell which issues are still open and warn
if any of these doesn't have an assignee.  So it could give you a quick overview
of the state of the release.

If we could get the BZ API working, I am sure we would find many other uses.

Simon

[1] https://bugzilla.readthedocs.io/en/5.0/api/core/v1/general.html

Re: gdb-7.11.1 re-spin update

[Joseph Myers]

On Tue, 3 May 2016, Simon Marchi wrote:

> I think that this particular problem could be efficiently solved with scripting.
> Apparently, Bugzilla now has an API [1], although I can't find how to use it on
> the sourceware BZ, maybe it's too old.
> 
> If that API was accessible, it should be easy to write a script that prints a
> nicely formatted list of all issues with target milestone == 7.11.1, ready to
> copy paste in the email.  It could also tell which issues are still open and warn
> if any of these doesn't have an assignee.  So it could give you a quick overview
> of the state of the release.

The REST API definitely works for sourceware Bugzilla; we use it for glibc 
to generate a list of fixed bugs for the NEWS file.

https://sourceware.org/git/?p=glibc.git;a=blob;f=scripts/list-fixed-bugs.py;h=51f3c36e693a67978ba58706499db132fefe1e4e;hb=HEAD

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: gdb-7.11.1 re-spin update

[Simon Marchi]

On 16-05-03 10:30 AM, Joseph Myers wrote:
> On Tue, 3 May 2016, Simon Marchi wrote:
> 
>> I think that this particular problem could be efficiently solved with scripting.
>> Apparently, Bugzilla now has an API [1], although I can't find how to use it on
>> the sourceware BZ, maybe it's too old.
>>
>> If that API was accessible, it should be easy to write a script that prints a
>> nicely formatted list of all issues with target milestone == 7.11.1, ready to
>> copy paste in the email.  It could also tell which issues are still open and warn
>> if any of these doesn't have an assignee.  So it could give you a quick overview
>> of the state of the release.
> 
> The REST API definitely works for sourceware Bugzilla; we use it for glibc 
> to generate a list of fixed bugs for the NEWS file.
> 
> https://sourceware.org/git/?p=glibc.git;a=blob;f=scripts/list-fixed-bugs.py;h=51f3c36e693a67978ba58706499db132fefe1e4e;hb=HEAD

Thanks, I'll have a look!

Just glancing at it quickly, it very much looks like what I was describing :).

Re: gdb-7.11.1 re-spin update

[Joel Brobecker]

I'm happy to report that I have subscribed to gdb-prs@ and setup
some mail filters to only see emails with a target milestone.

I'll try to look at the scripting suggestion later on.

All in all, this could be a nice improvement over the previous
situation.

-- 
Joel