<> ||<>|| 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 our bug procedures are documented here: https://wiki.ubuntu.com/MozillaTeam/Bugs/Procedures its not yet clear how we will the Todo and Triaged states ... but since confirmed still exists, there is no need to hurry JenFraggle: ok ... so basically our workflow is like this: 1. bugs come in as New (previously Unconfirmed) 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 ok 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 (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) ok 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" i see. i haven't done anything like this which so that makes it awkward to write about JenFraggle: its not needed to describe in detail ... just like above in your own words would be good JenFraggle: think about it like this: i just need to have an idea of what happens and at present I don't really know. this is really helpful 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 ok JenFraggle: let me show you an example wait a second np 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) i wondered why they were really short sometimes, those ones need to be retraced 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 how to retrace is out of scope for the introduction. ok ... lets go further ... if you have specific questions about this (e.g. when writing etc.) you can always ask yep sure 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 ok (note: we are still in incomplete) mt-testcase is a more or less simple task as well ok 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 makes sense so if you find a testcase you can either reproduce with that ... or maybe you cannot reproduce on your own 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 ok 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 ok 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 :) ok 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 ok in this way triagers get feedback and will probably learn. cool ok ... confirmed has again a few sub-states in general confirmed exists to find a solution for us right 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 ok 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 ok 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 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 ok 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 ok those bugs are probably the ones that need most knowledge about packaging and even C/C++ coding in some cases * JenFraggle shudders and are probably suitable for MOTUs or someone else interested in that :) * JenFraggle relaxes 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 ok 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) sure 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 cool 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) keep the punters happy and all that 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) ok if a bug doesn't find any valid tester it gets invalid as well at some point same of course for testcase makes sense 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]]