The following is a transcript describing the bug flow process.

Transcript

--> You are now talking on #ubuntu-mozillateam --- Topic for #ubuntu-mozillateam is Home of Ubuntu Mozilla Team - https://wiki.ubuntu.com/MozillaTeam | Bug Triagers please read: https://wiki.ubuntu.com/MozillaTeam/Bugs/ | Firefox trunk package source : https://code.launchpad.net/~asac/firefox/trunk | Mailing List: ubuntu-mozillateam@lists.ubuntu.com |

• Topic for #ubuntu-mozillateam set by Admiral_Chicago at Sun Jun 24 09:33:47 2007

<asac> our bug procedures are documented here: https://wiki.ubuntu.com/MozillaTeam/Bugs/Procedures

<asac> its not yet clear how we will the Todo and Triaged states ... but since confirmed still exists, there is no need to hurry

<asac> JenFraggle: ok ... so basically our workflow is like this:

<asac> 1. bugs come in as New (previously Unconfirmed)

<asac> when bugs come in as "New" someone has to look at it and decide whats next

• in general a bug can be a feature bug, a crash bug ... or a packaging bug for now we subsume feature bugs and packaging bugs. so basically its just ... either its a crasher ... or something else

<JenFraggle> ok

<asac> depending on this there are different activities that need to be done to get a bug started

• for crashers its getting a proper crash report ok ... when you see a "New" crash bug you move it to incomplete in case there is no crash report attached, the task that needs to get done is a simple wone: one: mt-needreport

<asac> (so when moving it to Incomplete you set the tag, so people that want to help on needreport bugs can get a good list bugs that they can process)

<JenFraggle> ok

<asac> need report task is simple: try to get the crash report the user forgot or didn't manage to attach

• once the crash report is attached it needs a retrace, so we tag it as mt-needretrace a retrace allows us to see details of a crash report: e.g. where did the crash occur in the program source code and what values were assigned to the variables at the time of the crash thus you can use a different name for retrace: "symbolize"

<JenFraggle> i see. i haven't done anything like this which so that makes it awkward to write about

<asac> JenFraggle: its not needed to describe in detail ... just like above in your own words would be good

• JenFraggle: think about it like this:

<JenFraggle> i just need to have an idea of what happens and at present I don't really know. this is really helpful

<asac> a crash reporter in its initial/raw form is just a huge blob of binary data ... that you cannot see anything about retracing aka symbolizing brings makes it readable for human eyes

<JenFraggle> ok

<asac> JenFraggle: let me show you an example

<asac> wait a second

<JenFraggle> np

<asac> e.g. this is a unsymbolized stacktrace: http://launchpadlibrarian.net/6493913/Stacktrace.txt

• while this is the symbolized one: http://launchpadlibrarian.net/6638744/retraced_Stacktrace.txt in the symbolized case you can see exactly in what function it crashed in (e.g. the top most line)

<JenFraggle> i wondered why they were really short sometimes, those ones need to be retraced

<asac> yes right

• they are just binary blobs without much sense ... so when you retrace you can see the backtrace ... that is often helpful to figure out the cause

<asac> how to retrace is out of scope for the introduction.

<asac> ok ... lets go further ... if you have specific questions about this (e.g. when writing etc.) you can always ask

<JenFraggle> yep sure

<asac> ok ... this is pretty much the end of the "special" treatment of crash reports.

• ok ... once you have symbolized a crash report you try to find duplicates in the same time you try to find a testcase ... which is actually the same that you do when you receive a non-crasher bug so ... when a testcase is needed you tag it as mt-testcase

<JenFraggle> ok

<asac> (note: we are still in incomplete)

• mt-testcase is a more or less simple task as well

<JenFraggle> ok

<asac> you try to get a good step by step description from the reporter

• how to reproduce the bug if he complains about broken GUI et al you also want screenshots basically you are done with mt-needtestcase if there is a description that allows others to verify if the bug exists

<JenFraggle> makes sense

<asac> so if you find a testcase you can either reproduce with that ... or maybe you cannot reproduce on your own

<asac> JenFraggle: in case you cannot reproduce you cannot say: "this is not a bug" ... as it might only appear in some specific setups

• JenFraggle: so you tag it mt-needtester JenFraggle: basically mt-needtester exists to verify if the testcase attached is good enough to reproduce by third parties

<JenFraggle> ok

<asac> task is like: you try to verify if the testcase works ... and if the bug is not reproducible for everyone you offer to assist to test things for a developer

<JenFraggle> ok

<asac> ok ... when you have a testcase that works a bug is not incomplete anymore

• but since you might not be really sure if a bug is complete now ... you tagg it mt-confirm and keep it in incomplete state mt-confirm is then a task for skilled people that can review testcase and crash report if its good enough to go on

  if it is, it goes to state confirmed

<JenFraggle> ok

<asac> otherwise the mt-confirm processor will drop instructions what is still needed and tagg accordingly.

• e.g. if he thinks that the testcase is not good enough he will tagg mt-needtestcase

<JenFraggle> ok

<asac> in this way triagers get feedback and will probably learn.

<JenFraggle> cool

<asac> ok ... confirmed has again a few sub-states

• in general confirmed exists to find a solution for us

<JenFraggle> right

<asac> solution means: either push things upstream (if we cannot deal with them) ... or evaluate a solution

• for pushing things upstream we have two substates: mt-upstream and mt-postupstream. mt-upstream exists because bugzilla.mozilla.org has loads of bugs ... and we don't want to post duplicates

<JenFraggle> ok

<asac> so we need a few people that try to find if a bug already exists.

• if we are pretty sure that a bug is not yet posted we move to mt-postupstream ... that task implies that someone reports an upstream bug and later volunteers to answer questions that mozilla developers might have

<JenFraggle> ok

<asac> ok ... if you posted the bug upstream you will tagg it mt-confirm ... so a developer or skilled triager can verify that the bug was submitted properly and that

• its on track ... e.g. the bug was confirmed upstream, which is essential that any mozilla developer will ever look at it

<asac> once the bug is properly posted upstream and on-track the ubuntu bug moves to state "in progress"

• as there is not much more to do for us we delegated the bug upstream

<JenFraggle> ok

<asac> ok ... for bugs that are important enough that we fix them on our own ... or if they are ubuntu specific bugs (like packaging problems)

• we tag things as mt-eval instead of mt-upstream this means that people should evaluate where the problem stems from and how we can fix things

<JenFraggle> ok

<asac> those bugs are probably the ones that need most knowledge about packaging and even C/C++ coding in some cases

* JenFraggle shudders <asac> and are probably suitable for MOTUs or someone else interested in that

* JenFraggle relaxes

<asac> there are cases where we want to help upstream (if they are important) ... those are mt-eval as well.

• ok ... as always when evaluation is done and solution is outlined in the bug you can tag mt-confirm so developer can again verify that it really is feasible and can be worked on

<JenFraggle> ok

<asac> for now the developer moves those bugs to In progress as well ... but i think we will use triaged as well

• not as well, but instead of it so in progress really means ... its in progress (like in someone is working on it)

<JenFraggle> sure

<asac> ok .. i think the rest is easy to understand ... when bugs that are in progress get fixed .. the ideally go to "Fix Committed" as soon as there is a patch available or the fix was really committed to some repository

• once we release a package with that fix it goes to "Fix Released" then we are done

<JenFraggle> cool

<asac> and have processed the bug from New to Fix Released

• most bugs that go to cofirmed should get fix released at some point (in an idealistic world)

<JenFraggle> keep the punters happy and all that

<asac> but hopefully most bugs won't go to confirmed, but are rejected in state incomplete as "Invalid"

• not hopefully ... but if you don't get a good testcase out of a bug you often just cannot fix it. so crashers without duplicates and no testcase get rejected after some time of inactivity (i think its 2 month now)

<JenFraggle> ok

<asac> if a bug doesn't find any valid tester it gets invalid as well at some point

• same of course for testcase

<JenFraggle> makes sense

<asac> however if the process is perfect there would be nearly zero Confirmed -> Invalid transitions

• but in reality that will happen as well i guess ok i think thats enough

CategoryMozillaTeam, CategoryBugSquad