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