Review Mozilla Upstream Bug Procedures (Intrepid Spec)
Blueprint: mozilla-upstream-bug-procedures-intrepid
Drafter: AlexanderSack
- Target: Intrepid and beyond
Intro
Mozilla Bugs can be roughly be sorted into three main blocks:
- crash bugs
- feature bugs
- wishlist bugs
We reviewed the currently established bug triaging procedures for mozilla bug during UDS in Prague 2008. This documents summarizes the results from that discussion and documents the deduced actions.
One particular focus of this session was improved upstream bug procedures.
Goals
- Better streamline the mozilla bug procedures, especially in regards of upstream bug triaging
- get more upstream involvement in crash processing
- get more QA team involvement through better documented procedures and clear guidelines for general as well as upstream bug triage for mozilla packages.
Current Practices
Crash Bugs
Crash bugs get filed in two ways: 1. auto submission using apport; 2. manual crash submission by users that see crashes and have apport disabled.
- Auto submitted crashes are auto retraced and an attempt to match the result with potential dupes is performed by the apport retracer service
- Manual crashes are produced using instructions on the wiki
(e.g. https://wiki.ubuntu.com/MozillaTeam/Bugs#head-c576e78d92cb3c959c271158b6ace98be835de83) and submitted as attachment. Auto dupe detection is not availalbe for such kind of crash reports and thus duplicates are frequently missed
Crash bugs with a valid stacktrace are triaged as followed:
- ask reporters to provide a testcase
- review stacktrace and match with the code involved to get an idea of the crash type
- try to find a duplicate in the upstream crash DB and if so, submit the crash upstream
Feature Bugs
Feature bugs are bugs about glitches and broken features. The procedure to triage those is:
- confirm that the bug is reproducible and that we have a good testcase
- confirm that this is not an ubuntu specific issue
- verify that the bug is not yet reported upstream
- forward the bug upstream once we are certain that there is no duplicate upstream
Wishlist Bugs
Wishlist bugs that are processed as follows
- confirm that the bug is comprehensible and that the idea is properly
- understood.
- verify whether its ubuntu specific
Ubuntu specific
- confirm that the wishlist bug properly describes the enhancement in the bug summary; set importance to "wishlist"; If the reporter considers his wishlist bug important enough he might want to lobby for it using mozillateam communication channels (irc, mailing list).
- developers regularly loog at wishlist and implement those that make sense to them.
Upstream specific
- verify that is not yet reported upstream
- point the reporter to the upstream mechanisms to get ideas heard. (e.g. dont forward on our own).
Identified Changes to Procedure
Crash Bugs
Upstream recognizes distributors and particular ubuntu as their de-facto main channel of distributing their linux builds and as this happens their attitude towards retrieving crash reports from distributors directly became more supportive of dealing with our crash submissions on their side.
Thus, the main change in dealing with crash bugs on ubuntu is that individual crashers will not be filed as bugs in launchpad anymore, but rather submitted to breakpad. Then we can use Breakpad to track our top-crashers and can open tracker bugs on them for them as appropriate bugs.
Feature Bugs
Discussion showed that upstream might accept more noise in their bugtracker in order to get everything on their plate that might be relevant.
Thus, we change the procedure to forward feature bugs even if we are not yet 100% sure that there is no duplicate filed upstream. Obviously we should still try hard to keep upstream noise low - just not as hard as in the past.
Wishlist Bugs
The general procedure for both, ubuntu and upstream wishlist bugs was found to work reasonable well; however, ubuntu wishlist bugs that dont have a supportive developer right away, should be directed to brainstorm instead of just doing nothing about it.
Implementation
Crash Bugs
Packaging
Enable crash report in ubuntu builds. Ensure that users that easily opt-in/opt-out in crash submission. If possible ship the crash reporter bits in a new binary package (e.g. xulrunner-1.9-crashreporter), but install it by default. Maybe adapt procedure to have users auto opt-in if they are running an ubuntu development release. In face of general instability we suggest to not enable it until ubuntu alpha2 releases.
Include Build information in submitted crash reports. The required information would basically be the lsb_release information. According to upstream, this might require an upstream fix.
Debugging Symbols
In order to allow breakpad to analyze our crashes we need to submit our debug symbols to them. Upstream offered to provide us with ssh access to upload those. It still need to be sorted with upstream how to best deal with the different library versions used by firefox builds in the various ubuntu releases.
Ubuntu QA + Triagers
Having our crash reports in breakpad allows us to shift from maintaing crash bugs in our bug tracker and pushing them upstream to regularly pulling for top crashers and spend our time only on investigating crashes that are of significant relevance. Thus, this specification suggests that QA ensures that all top-crashers for ubuntu builds get a proper launchpad and bugzilla.mozilla.org. This can be done by individual bug triagers, but might also be a suitable topic for Hug Days.
Feature Bugs
As outlined above, one of the goals is to get more feature bug submissions upstream and finally resolved. However, upstream forwarding requires cycles to follow up and thus it was identified as essential to get bugcontrol team members involved in this process.
The following steps appear to be essential to get to this new procedure in place:
- Instructions on the wiki that outline the procedure for forwarding mozilla
- bugs upstream.
- To monitor quality of our upstream submission, we will add a mechanism to
- identify ubuntu submissions in bugzilla. The mechanism used to accomplish this has to be coordinated with bugzilla admins. The mechanism should be documented on the instructions page above.
- regular mozilla upstream hug days could focus on reviewing upstream bugs,
- ensuring that top-crashers have a proper upstream and launchpad bug, _and_ induction of bugcontrol members on how to properly forward feature bugs.
Wishlist Bugs
As described above, no real action needs to be taken to improve this area except updating the available wiki documentation to match was was said in this specification.
Outstanding Issues / Notes
- (populate this place while implementing this)