I would like to add a 'tools' component to the Firefox OS product for the scripts that reside in the B2G repo's tools directory (https://github.com/mozilla-b2g/B2G/tree/master/tools). I'm open to suggestions on the name (or validity of adding this component). For example this would make it easier to track issues in the 'tools/get_about_memory.py' script which currently has open bugs in: FxOS::General, FxOS::GonkIntegration, FxOS::Performance, Toolkit::about:memory, Core::DMD. :jld, :mccr8 I would appreciate your feedback on naming, descriptions, default reviewers. Component Name: tools Product Name: Firefox OS Long Description: Issues relating to scripts found under the tools directory in the B2G project. Short Description: Issues relating to scripts found under the tools directory in the B2G project. Flags: Product defaults. Suggested reviewers: :jld, :mccr8, :erahm
Summarizing from IRC: I'm not sure if this is the right way to organize things. There's something to be said for having the tools belong to their respective areas if they're for larger areas like about:memory or the profiler — and there tend to be bugs that touch the gecko-repo part and and B2G-repo part. There definitely should be *some* agreed-upon scheme for where these bugs go.
Yeah, I don't really know. I don't think I've ever run that script and I'm not sure I've written code for it. toolkit:about:memory kind of sounds like a reasonable place for it already from a conceptual perspective, though it is quite FxOS specific. Kyle may have an opinion.
(In reply to Andrew McCreight (Away July 17-24) [:mccr8] from comment #2) > Yeah, I don't really know. I don't think I've ever run that script and I'm > not sure I've written code for it. toolkit:about:memory kind of sounds like > a reasonable place for it already from a conceptual perspective, though it > is quite FxOS specific. Kyle may have an opinion. By tools I was lumping in the gc_cc script and utils script as well.
> toolkit:about:memory kind of sounds like a reasonable place for it In my mind, that component is just for the actual about:memory page, i.e. the code in toolkit/components/aboutmemory. But people often use it for stuff that relates to the underlying memory reporters, which are spread all over the code base. Having a "core : memory reporting" module would make more sense for that, and then get_about_memory.py would fit in there nicely, though it wouldn't help Eric with the gc_cc and utils scripts.
it appears there isn't a consensus on if this request is to be honoured in its current form. would it be possible for you to update this bug with what component(s) you need created, or close the bug if no action is required? thanks.
I don't think we're going to get any consensus on this, we can just deal with the status quo.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.