…and what have i done so far? time for a summary (the long version is available at http://home.arcor.de/ak-47/linux/gnome-release-team.html ).
my task: “showstopper tracking and nagging”, means: nag developers and better control of bugzilla. well, howto? that was the question…and these have been my thoughts so far:
- 2006-08
(generally: not much time, lots of other work, and a bad modem-only connection in august and september, therefore not much done.)
i began with going through all the “blocker” bugs. i triaged and poked on some of them, but finally realized that this stuff wouldn’t help that much to fulfil my underlying aims. i should definitely take a look at those bugs from time to time, but this is not a high priority. - 2006-09-28
i then began (beside compiling the entire cvs head meta-gnome-desktop by using jhbuild) to clean up the NEEDINFO bugs, beginning with the oldest ones.
i think it is important that we have an up-to-date database, also with regard to which bugs do really exist. i hate real bugs rotting away just because somebody set them to needinfo without adding a reason, or because a reporter that has provided requested information has forgotten to reopen the bug (read: have had javascript disabled in his browser).
i triaged about 300 bugs on that weekend, so now we have less then 50 needinfo bugs left that are older than 6 months. - 2006-10-02
now it’s time to get through open/needinfo bugs that have an ancient gnome target milestone. this was only 11 bugs, fine; now there are still 2 bugs left. - 2006-10-05
the duplicate finder looks like one possible way to go, it’s an easy way to identify serious issues. - current affairs
- i’m mostly working by using the duplicates.cgi page and the GNOME 2.16 blocker buglist.
- filed bug 359885 and bug 363387 to get better results for duplicates.cgi. the latter one has been already fixed by olav, thanks!
- i’m mostly content with the feedback on the bugs that i have considered as most important and urgent, some of them got fixed, and some of them are in progress. at least we killed bug 350975 now which had hundreds of duplicates.
as i had already written, it would be interesting to find out which developers will be communicative and quick, and which ones will be lazy and unresponsive. so of course i try to use the traditional bugzilla comment as the first try to poke them, but sometimes i have to poke them on irc or by private email (yes, this has happened already). - there’s only few important gnome products still missing developer name information in bugzilla, i sent another reminder to d-d-l.
- a huge thank you to elijah for already putting a showstopper nagging draft online, i will have to update this with my impressions when our email discussion has come to an end. ;-)
- while evolution seems to be a bit more quiet at the moment with regard to evil crashers, nautilus definitely needs some love, as many of the duplicated crashers are nautilus issues. i’m glad to know that alex is looking at some of the main crashers, i cross my fingers and hope that he will be successful…
- working on setting up a list of products that bind to the gnome release schedule and those that do not bind by getting through the mailing list archives, as branching has to be announced. also should take a look at products which are rather unmaintained or deprecated (means: no posting about any branching for a long time and no cvs activity), but are not yet part of the unmaintained list – there are some candidates… :-) – i guess those products aren’t flagged as “deprecated” somewhere in the *bug database*, but it would be great to have an option to hide bugs of deprecated products on the duplicates.cgi site.
- another step to get faster and better fixing of important issues has been to improve and simplify the bugzilla stock answers, so that it’s easy for non-techie users to help us getting better stacktraces and requested information. this has happened already, next step is to simplify the GettingTraces wiki page. again, elijah has already come up with a proposal which now has become the default, and which we have improved a little bit so that i know hope that it has become easier to encourage users to provide useful stacktraces.
- compiling gnome: i’m still stuck with compiling epiphany which does not work for me. second issue: my laptop is very good in overheating when compiling stuff. so i will have to poke a friend to open it and clean it.
- some thoughts on public showstopper reviews
- a combination of duplicates.cgi and feedback of the bugsquad, developers
- also consider GnomeGoals or gnome-doc-utils migration to become showstoppers
- important to also have feedback from the bugsquad to have additional impressions of “what is important”
- also consider the different importance of applications – the number of open bugs is an easy measure here.
- make sure that everybody has added some developer name information to bugzilla
- do criticize developers that are unresponsive
- send to d-a-l and/or d-d-l?
- i of course i volunteer for this, though i’d say that something like “every two weeks” would be a good period
