Every release the various ubuntu teams focus on "release blocker bugs". These are bugs that are "High" or "Critical" in importance, and are targeted to the release. Of course they also have to be assigned so that someone knows about them and can work on them.
Of course, every release the desktop team fixes lots of bugs that are not release blockers. seb128 is leading an effort to organize the team to focus on the "right" set of these non-release blockers to fix. These are personal goals that the desktop team members sets for itself.
Process
seb128 is combing through bugs that he considers addressable, and assigning the ones that he thinks will be most valuable to users if fixed to canonical-desktop-team. He sets the importants and targets to Lucid as well. pitti will then assign to specific engineers as needed. Of course, anyone is free to fix these bugs.
Bughugger
I am using bugger to watch this project. The version of bughugger that is currently packaged in universe calculates gravity and looks for attached patches. Unfortunately this makes the queries take so long, that it is basically impossible to use. (I've fixed this in my local copy, but haven't pushed the changes yet. By "fix" I mean removed the slow features.)
However, the JSON searches are working very well. From the bughugger search menu, choose JSON Searches, and you'll get a list of searches that run on a cron job on bdmurray's server.
After the results load, I can look for bugs assigned to the Canonical Desktop Team.
Because we worked in three iterations for Lucid, and minimized work for the third iteration, I am hopeful that we have a bit more time for bug fixing this cycle. However, even if the amount of bug fixing stays the same, I expect that having seb128 on point for choosing the highest impact bugs organized in a single list will help the best set of bugs get fixed by the desktop team, enhancing the general community quality efforts.
F-Spot
On a side note, RAOF has recently joined the desktop team as a Canonical supported employee! One of his first tasks was to implement the f-spot features required for the default application selection blueprint. F-spot now handles in situ editing of files. Which means no need to load images into the library to edit them, and no need to load up the gimp just do a quick crop! I cropped these screen captures using f-spot and it worked swimmingly. Thanks RAOF!
No comments:
Post a Comment