Would "Core :: Debugging: gdb" be a good bugzilla component?

[Andrew Sutherland]

Right now the gecko gdb pretty-printers have been tracked using bugs in 
"Core :: Build Config" because that's where the bug that first added 
them lived.  That component currently has 1773 bugs in it, 3 of which 
involve gdb, and with daily activity of ~10 bugs a day.  I think a more 
targeted component could be useful since gdb users could watch the 
component without getting the comparative fire hose of Build Config.  
Right now notifications would need to come via explicit CC or watching 
for changes in dependencies of the existing bugs.


The component would presumably cover not just the gdb pretty printers 
but also other gdb related issues.


The triggering factor is that I made a foolish mistake with the 
nsTHashtable pretty-printer.  It has been telling lies, see 
https://bugzilla.mozilla.org/show_bug.cgi?id=1303174 (fix on inbound, 
with apologies to anyone misled by the broken pretty-printer).


Andrew

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Would "Core :: Debugging: gdb" be a good bugzilla component?

[Andrew McCreight]

You could also just file things like that in the corresponding component,
and maybe create some kind of meta bug for gdb hooks. So debugging for
nsTArray would be filed in XPCOM, etc. I think that's the way it works for
Javascript engine related debugging hooks. Failing that, having the nested
gdb inside Debugger seems like overkill given that no top level
Core::Debugger component exists right now. Maybe if in the future there's a
flood of gdb and lldb bugs it would be further subdivided.

On Fri, Sep 16, 2016 at 7:50 AM, Andrew Sutherland <
asutherl...@asutherland.org> wrote:

> Right now the gecko gdb pretty-printers have been tracked using bugs in
> "Core :: Build Config" because that's where the bug that first added them
> lived.  That component currently has 1773 bugs in it, 3 of which involve
> gdb, and with daily activity of ~10 bugs a day.  I think a more targeted
> component could be useful since gdb users could watch the component without
> getting the comparative fire hose of Build Config.  Right now notifications
> would need to come via explicit CC or watching for changes in dependencies
> of the existing bugs.
>
> The component would presumably cover not just the gdb pretty printers but
> also other gdb related issues.
>
> The triggering factor is that I made a foolish mistake with the
> nsTHashtable pretty-printer.  It has been telling lies, see
> https://bugzilla.mozilla.org/show_bug.cgi?id=1303174 (fix on inbound,
> with apologies to anyone misled by the broken pretty-printer).
>
> Andrew
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Would "Core :: Debugging: gdb" be a good bugzilla component?

[Jim Blandy]

I think a meta bug would meet all the requirements.

- You'd have to tell people about the component anyway, just as you would a
metabug.

- Components have textual names instead of numbers, but you can give bugs
names that you can use in the blocker field.

- You can get mail for new bugs added as blockers to the metabug, which is
somewhat like watching a component.


On Fri, Sep 16, 2016 at 9:48 AM, Andrew McCreight 
wrote:

> You could also just file things like that in the corresponding component,
> and maybe create some kind of meta bug for gdb hooks. So debugging for
> nsTArray would be filed in XPCOM, etc. I think that's the way it works for
> Javascript engine related debugging hooks. Failing that, having the nested
> gdb inside Debugger seems like overkill given that no top level
> Core::Debugger component exists right now. Maybe if in the future there's a
> flood of gdb and lldb bugs it would be further subdivided.
>
> On Fri, Sep 16, 2016 at 7:50 AM, Andrew Sutherland <
> asutherl...@asutherland.org> wrote:
>
> > Right now the gecko gdb pretty-printers have been tracked using bugs in
> > "Core :: Build Config" because that's where the bug that first added them
> > lived.  That component currently has 1773 bugs in it, 3 of which involve
> > gdb, and with daily activity of ~10 bugs a day.  I think a more targeted
> > component could be useful since gdb users could watch the component
> without
> > getting the comparative fire hose of Build Config.  Right now
> notifications
> > would need to come via explicit CC or watching for changes in
> dependencies
> > of the existing bugs.
> >
> > The component would presumably cover not just the gdb pretty printers but
> > also other gdb related issues.
> >
> > The triggering factor is that I made a foolish mistake with the
> > nsTHashtable pretty-printer.  It has been telling lies, see
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1303174 (fix on inbound,
> > with apologies to anyone misled by the broken pretty-printer).
> >
> > Andrew
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform