Archive for November, 2006

bug flood.

Thursday, November 30th, 2006

(welcome, dear planet gnome. who i am? check bugzilla, or the evolution archives.)

looks like luis was already scared by my previous chart, so here’s another one: the number of nautilus bugs filed per day, within the last months:


(yes, negative values are possible, because reports can be moved from nautilus to gnome-vfs, for example.)

just see how new releases of wide-spread distributions can ruin the sleep of the gnome bugsquad for weeks, and lead to burn-out at the end. more people triaging bugs could be the workaround, and more automation should be the long-term strategy.

bug flood.

Wednesday, November 29th, 2006

played around with bugzilla.gnome.org’s reports.cgi and chart.cgi, and finally ended up in gnumeric. the chart should describe the situation pretty clearly – no more words, need sleep.

leaving evolution.

Tuesday, November 28th, 2006

leaving evolution.

we’ve come a long way, baby…:

two weeks ago, i finally officially announced that i retire from being the evolution bug master, some weeks after already having retired internally. it really hurts to leave a project that you’re passionate about after several years.

for the reasons:
as time went by, involvement increased.
i once asked questions on the user mailing list, answered by rodo and guenther.
i didn’t unsubscribe and began answering trivial questions. looks like that in march 2004, i kicked off at the mailing list, and some people were happy when i finally became familiar with bugzilla.ximian.com (funny sidenote: i still haven’t read the triage guide yet) and started triaging on one of gerardo’s bug days, and it looks like i heavily cleaned up the evolution bug database by marking duplicates and closing obsolete reports. the amount of open reports decreased from 3000 to 2300 within a few months (no, that’s not all just because of me, of course). when i did not feel safe with a decision, i visited evolution’s irc channel just to drop in, ask questions to gerardo, and drop out (yes, please laugh at this behaviour now, but modem connections also mean losing money).
later, i began to write trivial string patches, test and review patches, discuss stuff with developers, developing the grand plan (TM), and attend the team meetings. after nags had left evolution, developers began to call me the bugmaster.

this was fun, a lot of work (read: time), and some responsibility. as everybody has to earn a living, i had a deal with novell for the last months to get paid for working half-time on evolution. beside that, i was asked to become a member of the gnome release-team, and elijah, vincent and luis convinced me of joining.
as a follow-up deal wasn’t offered, i had to look out for a new job (currently working at the university). release team, the general bugsquad work, earning a living and being the evolution bugmaster on a volunteer basis does not work out. yes, i still need time for living a life outside of the computer world, and i sometimes love being offline for a few days. therefore i had to make a decision – and swimming upstream looks more important.

with regard to evolution, i will go back to the start – by answering user questions.

though evolution has become much more stable within the last two years, imo it is in urgent need of a bugmaster (i doubt that general gnome triagers have enough knowledge for evolution-specific non-crasher reports, and i doubt that the evolution developers have enough time to answer user questions). perhaps, at some indefinite future date, i would return.
all my best wishes to the evolution project, and thanks for an awesome, great and sometimes stressful time, and for many new friends. i have learnt a lot about software project management, and i now hope that i can also improve the bugzilla situation for the entire project – GNOME.

into the void we have to travel…

some expectations for the future of gnome user feedback.

Wednesday, November 15th, 2006
  1. add a “please write in english.” sentence. perhaps evey seventh or eighth bug report is not in english. i know some languages, but not all of them. please request a string and ui freeze so we get this in for GNOME 2.16.3, otherwise this will drive me (and the users who have to rewrite their entire report in english) nuts.
  2. add a sentence that an account will be created and that the submitted email address will be visible for people that have logged in into our bug tracking system. just for privacy reasons.
  3. the non-trivial one which was already covered by olav’s latest posting: make bug-buddy display feedback received from bugzilla.gnome.org. as the GNOME community and user base grows, we have to handle more and more reports, which either means that the bugsquad needs more volunteer triagers, or that we need more automation. the latter one should be the way to go. now imagine what will be possible by doing this: we can reject duplicates and tell the user about this, we can tell the user that his issue is fixed already and that his distribution provides an update, we can tell the user that he is using an obsolete version and directly reject the bug report. if every gnome bugzilla product has a boolean value providing its maintenance state, we can also tell the user that he/she should not expect fixes, as that product is currently unmaintained.
    we should also take care of i18n here by submitting the user’s LANG setting, so the feedback language can be adjusted.
    is anyone already planning this? bkor, fer? a must-have for 2.20, and a would-be-great for 2.18. thanks.

it’s a very great honour to me…

Friday, November 10th, 2006

…so i thought i should respectfully take a break here (at least for one night), before moving on and overtaking luis:

evolution bug triaging information.

Friday, November 3rd, 2006

I wrote this about a year ago, now it’s time to publish this so it becomes easier for any potential successors willing to do this. so before the last person that remembers some ximian bugzilla wisdom finally leaves the project, it is time for a knowledge transfer before all this information would get lost.
I’d like to thank Novell for an interesting time, 7 t-shirts, a suse box, and a few bugs and bucks. ;-)

=======General.=======

  • Why Everyone Needs A Bugmaster by Luis.
  • Many users are just pissed if their software crashes, only few users spend time on filing a bug report, so be polite. Say thanks. (Just use the nice stock responses if you have enabled Javascript in your browser.) If you have an idea what could be a solution to the reporter’s problem, tell them, and set to NEEDINFO. If you need additional information by the reporter, explain them which additional information you need, and even more important: Tell them how they can get the additional information that you need. If you set a bug report to NEEDINFO, you must tell the reporter to REOPEN it when he adds more information. I have found many bugs where this was not told to the reporter, and so the bug was just forgotten. CC yourself if you like to. Make users happy, not necessarily yourself. ;-)
  • If you add comments refering to another existing bug, the text “bug xxxxxx” (where xxxxxx is the number of some bug report) is automatically transformed to a hyperlink. So use “bug 987654″ instead of “#987654″ or even “987654″!
  • Use keywords and get familiar with them. Keywords are extremely important for searching (also for searching for duplicates!).
  • Some Evolution-specific keywords would be just useless for other applications then Evolution. Therefore they are on the Status whiteboard. Use it like “evolution[filters]” or “evolution[vfolders]“, please use the “evolution” namespace so this does not interfere with other Gnome applications. Take a look at the complete list of Evolution’s status whiteboard keywords. I have also added the entries “evolution[codecleanup]” and “evolution[nosip]“. You can also use the whiteboard to improve your own workflow by using custom tags, see the Status whiteboard neat tricks.
  • If a bug report misses a version number and you can find it out, add it!
  • Use the severity. People reporting bugs often use the preset (“normal”) or do not set the severity to “enhancement” though their wish definitely is an enhancement and not a bug.
  • If you try to reproduce a bug, also add information about your own version and distribution.
  • Crashes with stacktraces should be kept “unconfirmed” until they can be reproduced. If they include symbols and line numbers *and* are from an uptodate version, please set the status to NEW.
  • If you like to be kept informed, use the weekly report.
  • Take a look at Evolution’s Product Specific Traiging Guidelines. Update them, if necessary.
  • When triaging, be aware which period of the Gnome development currently takes place. Take a look at the Gnome timetable. For example, if there’s a UI Freeze, it is not allowed to change the UI. Stable releases are under String Freeze always. If strings really must changed or added, you must inform the gnome-translators mailing list. See e.g. bug 321640.
  • There’s a (developer) wiki available with information e.g. about the architecture or compiling from cvs: http://go-evolution.org.
  • Searching for duplicates:
    • try synonyms. also think of gerunds, e.g. search both for “delet” and “remov”. It covers both “delete” and “deleting”.
    • crashs and their stacktraces: use the simpledupfinder. Only mark them as duplicates if they fit exactly, if they are quite similar add a comment. If you close a bug as a duplicate because of a stacktrace, explain why you close it. Users/reporters must not take a look into the stacktraces, and sometimes the same crashs happen in different situations so one gets irritated if the bug includes a totally different description then the original one.
  • Last, but not least: If necessary, snap at the developers. It’s not the aim to be best friends, but to be productive and to have happy customers. You’re part of the marketing. Deal with it.

=======Common requests/tasks and their links (partially unpleasant, repetitive gruntwork ;-).=======

General Bugzilla stuff, not Evolution related:
Query page
| Weekly Reports
| simpledupfinder
| Triage guide
| CVS HowTo
All NEEDINFO bugs (Evo, EDS, Gal, GtkHtml)
All non-closed memory and performance keyworded bugs
Component Status:
Evo
| EDS
| GtkHtml
| GAL
All open+unconfirmed+needinfo bugs:
Evo
| EDS
| GtkHtml
| Gal
| All
All open+unconfirmed bugs:
Evo
| EDS
| GtkHtml
| Gal
| All
All unconfirmed bugs:
Evo
| EDS
| GtkHtml
| Gal
| All
Recent Milestones (includes needinfo):
Evo
| GtkHtml
Patch Status Report:
Evo
| EDS
| GtkHtml
| Gal
Bugs not yet commented on:
Evo
| EDS
| GtkHtml
| Gal