Hi,
Tagging bugs is not only good practice but makes tracking and sorting so much easier. With this in mind I came up with a list of tags that can be consulted when reporting bugs. Please take a look at:
http://wiki.linaro.org/Process/Bugs/Tags
Ubuntu bug tags [1] also still apply, the Linaro specific ones are just to further classify bugs for Linaro.
Please feel free to suggest changes/corrections.
Regards, Jamie.
Hi,
On Tue, Sep 21, 2010 at 2:47 PM, Jamie Bennett jamie.bennett@linaro.org wrote:
Hi,
Tagging bugs is not only good practice but makes tracking and sorting so much easier. With
Maybe we could also pull out some metrics, such as numbers of bug with each tag, and age/severity distribution etc.? Would that be easy to set up?
Cheers, ---Dave
On 21 Sep 2010, at 14:54, Dave Martin wrote:
Hi,
On Tue, Sep 21, 2010 at 2:47 PM, Jamie Bennett jamie.bennett@linaro.org wrote:
Hi,
Tagging bugs is not only good practice but makes tracking and sorting so much easier. With
Maybe we could also pull out some metrics, such as numbers of bug with each tag, and age/severity distribution etc.? Would that be easy to set up?
Funny you should say that, I'm working on bug metrics at the moment with Kate Stewart, the Ubuntu Release Manager. I'll report back when I have more.
Cheers, ---Dave
Regards, Jamie.
On 21 Sep 2010, at 14:54, Dave Martin wrote:
Hi,
On Tue, Sep 21, 2010 at 2:47 PM, Jamie Bennett jamie.bennett@linaro.org wrote:
Hi,
Tagging bugs is not only good practice but makes tracking and sorting so much easier. With
Maybe we could also pull out some metrics, such as numbers of bug with each tag, and age/severity distribution etc.? Would that be easy to set up?
As a exercise in learning launchpadlib I put together a python script to gather information on interesting bug tags and put them on the wiki. My local cron job gathers this information in such a way to allow historic tracking, so we will be able to see the metrics for each tag. When I have enough data I will amend the script to include that.
The script is at:
http://code.edge.launchpad.net/~jamiebennett/+junk/bug-track
(beware, its very early days and it isn't the greatest code, tags need to be passed in rather than hard-coded e.t.c)
and the output can be seen at:
http://wiki.linaro.org/Bugs/Tagged
Cheers, ---Dave
Regards, Jamie.
On Mon, Sep 27, 2010 at 09:10:49PM +0100, Jamie Bennett wrote:
The script is at:
http://code.edge.launchpad.net/~jamiebennett/+junk/bug-track
(beware, its very early days and it isn't the greatest code, tags need to be passed in rather than hard-coded e.t.c)
Nice job!
You probably want to have a list of pillars to search through instead of just looking through "ubuntu" and "linaro"; I wonder if it makes sense for us to have a page where we registar all Linaro-related Launchpad projects to ensure we actually know where to look. What do you think?
The other alternative is to change our tag names to be unique -- i.e. prefixed with linaro-, so i.e. linaro-igep -- and then get somebody in Launchpad to implement searching for tagged bugs across all projects registered.
I think the first suggestion is probably good enough and depends only on you; the only downside is that if you file, say, an Xorg bug with an "igep" tag, you probably won't have Xorg listed as a pillar to search through. It would probably have an Ubuntu or Linaro bug filed against it, though, which is why I think it's not a big problem.
On 27 Sep 2010, at 21:22, Christian Robottom Reis wrote:
On Mon, Sep 27, 2010 at 09:10:49PM +0100, Jamie Bennett wrote:
The script is at:
http://code.edge.launchpad.net/~jamiebennett/+junk/bug-track
(beware, its very early days and it isn't the greatest code, tags need to be passed in rather than hard-coded e.t.c)
Nice job!
You probably want to have a list of pillars to search through instead of just looking through "ubuntu" and "linaro"; I wonder if it makes sense for us to have a page where we registar all Linaro-related Launchpad projects to ensure we actually know where to look. What do you think?
Sure. The pillar name is passed in when calling the script so could be any project. Getting a list of these projects is a good idea but will need to be maintained.
I have another script called from a cron job which just calls 'bug-track ubuntu' and 'bug-track linaro', this of course could be anything. Currently each project is presented separately on the wiki page but I could combine that information.
The other alternative is to change our tag names to be unique -- i.e. prefixed with linaro-, so i.e. linaro-igep -- and then get somebody in Launchpad to implement searching for tagged bugs across all projects registered.
I think the first suggestion is probably good enough and depends only on you; the only downside is that if you file, say, an Xorg bug with an "igep" tag, you probably won't have Xorg listed as a pillar to search through. It would probably have an Ubuntu or Linaro bug filed against it, though, which is why I think it's not a big problem.
Right and if we suspect that we could get 'interesting' bugs in a project we could just add it to the list of projects to check.
Christian Robottom Reis | [+55] 16 9112 6430 | http://launchpad.net/~kiko
Regards, Jamie.
On Mon, Sep 27, 2010 at 09:28:45PM +0100, Jamie Bennett wrote:
Sure. The pillar name is passed in when calling the script so could be any project. Getting a list of these projects is a good idea but will need to be maintained.
Here's a stab at a first set:
* ubuntu * linaro * linaro-toolchain * linaro-toolchain-wg * linaro-kernel * linaro-kernel-wg * linaro-middleware-wg * linaro-pm-wg * linaro-seeds * linaro-image-configs * linaro-image-tools
I think there are a bunch missing here that are related to infrastructure.
I can just keep these in the description for the Linaro project. Do you think that's sensible enough?
BTW, should we be somehow merging linaro-toolchain-wg and linaro-toolchain? Same for the kernel projects? One of each seem to be stubs just holding blueprints anyway, right
BTW2: Should we create a linaro-tools or linaro-infrastructure group that we use to collect our various projects and include -seeds, -image-configs and -image-tools there?
I have another script called from a cron job which just calls 'bug-track ubuntu' and 'bug-track linaro', this of course could be anything. Currently each project is presented separately on the wiki page but I could combine that information.
Yeah, I think you should combine it into a single list. You could optionally present the projects affected as a list similar to your tags list -- but it may be irrelevant and just narrow the columns out unnecessarily.
On Mon, Sep 27, 2010 at 10:55 PM, Christian Robottom Reis kiko@linaro.org wrote:
BTW2: Should we create a linaro-tools or linaro-infrastructure group that we use to collect our various projects and include -seeds, -image-configs and -image-tools there?
group as in team or superproject (like launchpad.net/mozilla) ?
On Tue, Sep 28, 2010 at 10:40:26AM +0200, Alexander Sack wrote:
On Mon, Sep 27, 2010 at 10:55 PM, Christian Robottom Reis kiko@linaro.org wrote:
BTW2: Should we create a linaro-tools or linaro-infrastructure group that we use to collect our various projects and include -seeds, -image-configs and -image-tools there?
group as in team or superproject (like launchpad.net/mozilla) ?
The precise term is "project group", but yes. ;-)
On Mon, Sep 27, 2010, Christian Robottom Reis wrote:
The other alternative is to change our tag names to be unique -- i.e. prefixed with linaro-, so i.e. linaro-igep -- and then get somebody in Launchpad to implement searching for tagged bugs across all projects registered.
Yeah, it's a bit sad that this exists only on the web UI https://bugs.launchpad.net/bugs/+bugs?field.tag=igep
On Tue, Sep 28, 2010 at 9:10 AM, Jamie Bennett jamie.bennett@linaro.org wrote:
On 21 Sep 2010, at 14:54, Dave Martin wrote:
Hi,
On Tue, Sep 21, 2010 at 2:47 PM, Jamie Bennett jamie.bennett@linaro.org wrote:
Hi,
Tagging bugs is not only good practice but makes tracking and sorting so much easier. With
Maybe we could also pull out some metrics, such as numbers of bug with each tag, and age/severity distribution etc.? Would that be easy to set up?
As a exercise in learning launchpadlib I put together a python script to gather information on interesting bug tags and put them on the wiki. My local cron job gathers this information in such a way to allow historic tracking, so we will be able to see the metrics for each tag. When I have enough data I will amend the script to include that.
The script is at:
http://code.edge.launchpad.net/~jamiebennett/+junk/bug-track
(beware, its very early days and it isn't the greatest code, tags need to be passed in rather than hard-coded e.t.c)
and the output can be seen at:
I've had a go at Toolchain WG specific tags here: https://wiki.linaro.org/MichaelHope/Sandbox/Tags
The idea is to be able to separate bugs, testsuite regressions, and tasks from one another while also separating speed from size tasks. If they look good, I'll merge them into the main tags page.
I had a quick play with one of my helpers. This link lists all gcc-linaro bugs grouped by tag: http://ex.seabright.co.nz/helpers/tickets/gcc-linaro?group_by=tags
which gives this interesting section: http://ex.seabright.co.nz/helpers/tickets/gcc-linaro?group_by=tags#bugs%20%2...
which highlights the 16 bugs that are actual bugs from the ~60 logged 'bugs'.
-- Michael
On Tue, Sep 28, 2010 at 04:01:44PM +1300, Michael Hope wrote:
I've had a go at Toolchain WG specific tags here: https://wiki.linaro.org/MichaelHope/Sandbox/Tags
Two comments on these:
- Your definition of regression deviates slightly from what is normally considered a regression (a regression as compared to previous versions).
- I'm not sure what "task" is useful for -- tool automation of some sort? At any rate it's hard to draw an absolute line between task and bug.
The idea is to be able to separate bugs, testsuite regressions, and tasks from one another while also separating speed from size tasks. If they look good, I'll merge them into the main tags page.
I think most of these are pretty toolchain-specific, so they should be sectioned off or kept in a TCWG page and linked to there, I think.
I had a quick play with one of my helpers. This link lists all gcc-linaro bugs grouped by tag: http://ex.seabright.co.nz/helpers/tickets/gcc-linaro?group_by=tags
Might make sense for you guys to actually build a single tool rather than reimplementing both, right? ;-)
On Wed, Sep 29, 2010 at 10:35 AM, Christian Robottom Reis kiko@linaro.org wrote:
On Tue, Sep 28, 2010 at 04:01:44PM +1300, Michael Hope wrote:
I've had a go at Toolchain WG specific tags here: https://wiki.linaro.org/MichaelHope/Sandbox/Tags
Two comments on these:
- Your definition of regression deviates slightly from what is normally considered a regression (a regression as compared to previous versions).
The 'regression' tag means a regression compared to the upstream version this forked from, so I think it fits the meaning of regression.
- I'm not sure what "task" is useful for -- tool automation of some sort? At any rate it's hard to draw an absolute line between task and bug.
The things in Launchpad are really issues - a mix of bugs, tasks, and (small) feature requests. I need a way of separating bugs, which we need to track and quickly reduce, from tasks which are improvements with a longer schedule. I don't see any fuzzyness there - something is either a bug or 'other', which I call a task.
The idea is to be able to separate bugs, testsuite regressions, and tasks from one another while also separating speed from size tasks. If they look good, I'll merge them into the main tags page.
I think most of these are pretty toolchain-specific, so they should be sectioned off or kept in a TCWG page and linked to there, I think.
The main page has sections that are WG specific so I thought they should end up there.
I had a quick play with one of my helpers. This link lists all gcc-linaro bugs grouped by tag: http://ex.seabright.co.nz/helpers/tickets/gcc-linaro?group_by=tags
Might make sense for you guys to actually build a single tool rather than reimplementing both, right? ;-)
Ah, it's the good old case of needing something now and it being as cheap to automate as to do by hand. All of these should be taken over by Infrastructure, and thats one of the things that James, Mounier, and myself talked about this morning.
-- Michael
On Wed, Sep 29, 2010 at 10:43:00AM +1300, Michael Hope wrote:
- Your definition of regression deviates slightly from what is normally considered a regression (a regression as compared to previous versions).
The 'regression' tag means a regression compared to the upstream version this forked from, so I think it fits the meaning of regression.
Well, that's a more specific instance of regression, which probably wouldn't fit others idea of it. If you use the wider definition, then I think it's candidate for a Linaro-wide tag. If you use the narrower one, then you should probably use upstream-regression.
- I'm not sure what "task" is useful for -- tool automation of some sort? At any rate it's hard to draw an absolute line between task and bug.
The things in Launchpad are really issues - a mix of bugs, tasks, and (small) feature requests. I need a way of separating bugs, which we need to track and quickly reduce, from tasks which are improvements with a longer schedule. I don't see any fuzzyness there - something is either a bug or 'other', which I call a task.
Well, you're likely to have tasks this cycle (falling out of planning) that are basically fixing bugs in some tools. Maybe you're saying that these would be bugs, though.
-
Alexander Sack -
Christian Robottom Reis -
Dave Martin -
Jamie Bennett -
Loïc Minier -
Michael Hope