Product Reorganization
The current organization of Maemo Bugzilla has some flaws. I won’t repeat the reasons here, see for example the Getting Nokia involved in bugs.maemo.org wikipage if interested.
Quim has come up with a helpful draft for reorganizing the products and components that has received several iterations now after integrating my own ideas and analyzing structures and components in both Maemo Bugzilla and Nokia’s internal bugtracker. In short: Split applications from the underlying platform, and getting prepared for where to add the new Fremantle products (like Meta Tracker or clutter).
Implementing this means to move a lot of components from A to B. This will trigger thousands of emails. While a few Maemo folks will hopefully send me some chocolate, most average people will hate me for spamming their mailboxes. So I prefer doing this on one day and completely disable sending Bugzilla mail (and probably add a warning banner one week in advance on every Bugzilla page).
I want to get this done before the Fremantle Alpha SDK gets released. Comments on the draft welcome.
Virtual QA Contacts
Bugzilla provides the concept of having QA Contacts and Default Assignees on a per-component level (components like Bluetooth are a sub-level of products like Connectivity are a sublevel of a categorization). QA Contacts and Default Assignees are just “users”, and every user in Bugzilla has an email address that does not need to be a valid one, let me explain:
If you are interested in getting all bugmail for a specific component, you subscribe to the email address of the particular QA Contact by adding it to your watchlist in your Email preferences in Maemo Bugzilla.
Currently there are lots of QA Contacts and Default Assignees ending with @maemo.org and some newer ones with @maemo.bugs.
Problem: foo@maemo.org email addresses exist in reality. It’s a bit unlikely that an individual will apply for the email address browser_bugs@maemo.org, but nevertheless it’s IMO bad to use an existing real domain.
Instead, I prefer to constantly use aliases with the non-existing top-level domain “.bugs” (like browser_bugs@maemo.bugs) – this is also what GNOME Bugzilla is doing by using a -maint@gnome.bugs suffix, and it has worked out quite well. (Another nice side effect of using alias is that you don’t have to reassign all bugs when a developer in a company moves on to maintain a different component – instead the former developer just removes the alias from his watchlist, and the new developer adds it to his watchlist. Less bugmail noise for everybody.)
So I’d like to harmonize this, one big problem though: Some of these addresses might exist in reality. If e.g. “sdk_bugs@maemo.org” is a real user and not a virtual one, and I change this to “sdk_bugs@maemo.bugs”, sdk_bugs@maemo.org will of course not receive any emails anymore. Need to take a look which of these users are correctly marked as inactive and probably check for the rest of them. :-(
Feature Jam (Go vote!)
Published a very first Feature Jar for the community and Nokia product managers one week ago. It’s rough and will soon receive another iteration. This is planned to happen monthly now. Keep in mind that Nokia handles feature requests differently from “real” bugs (other persons to contact), hence this is seperate from Bug Jars.
You can raise your voice by voting for existing bug reports and enhancement requests (much prefered to “I want this too” comments)! Every bug report has a “Vote for this bug” link. Use it! Also see the My Votes page for more information.
Cleaning up
I’ve also been spending some time on triaging dozens of old bugs (bugs, not enhancement requests) to continue cleaning up. There’s still enough reports that have never seen any comment added though, and sometimes I even have to close valid non-critical Diablo issues as WONTFIX because the issue will not exist in Fremantle anymore (radical code changes) and because the corresponding Nokia developer teams have already moved on to spend their time on Fremantle only except for critical issues. I always feel a bit sorry for this, but I understand that a company has to set priorities on where to use manpower and resources…
However, I think we’re on a good way – if you want to help, just pick up an old bug and try to reproduce it with the current Diablo. If it’s still an issue, update it by leaving a comment and setting the “Version” field to the version that you have used for testing. If you can’t reproduce, also add a comment telling us the version you’ve used and the steps you took to reproduce. Even if you only take a look at one bug, it’s an appreciated help! Also see the Bugsquad wiki page for more info in general.
Viel zu lang, ich les das jetzt nicht. Dafuer schreib ich sinnlose Beitraege hier als Kommentar:
Ich hab neulich nachgedacht ueber synthetische Saetze a priori. Angeblich ist “Gott existiert” oder aber auch “Gott existiert nicht” sowas. Kant und mein Professor sind der Meinung sowas soll es geben. Also wenn du mich fragst ist das ein analytischer Satz, denn die Existenz von Gott ist schon im Wort Gott enthalten; ich erinnere hier an den ontologischen Gottesbeweis. Sein ist zwar angeblich kein reales Praedikat, aber da behauptet eben jener Kant 500 Seiten lang was ganz anderes ehe er zu diesem Schluss kommt.
Mir ist halt doch die Existenzphilosophie lieber. Wie auch immer. Schoenen Abend.
Please do forward Maemo bugs to Debian! It would be great if Maemo folks could get more involved in Debian, or even merge Maemo into Debian.
@foo: Can you elaborate a bit what “get more involved” exactly means for you? (or a valid email address that I could contact you :-)
I’ve been forwarding bugs upstream to GNOME or Busybox when it made sense. I’ve not worked with Debian’s bugtracker so far – please elaborate on the advantages.
Note that I’ve always campaigned against disabling email.
If someone is getting a lot of email from Bugzilla and they don’t like it, then they did something wrong (“they bit off more than they could chew”). I sign up for bugmail so that I can track changes. If someone signs up to track more changes than they can handle then they need to rethink their choices.
Instead of disabling mail, I’d suggest a dry run. We did most of this for the last mozilla reorg, but this is a slight improvement:
1. On a clone of Bugzilla, change the mail daemon to have no access to the outside world and have it queue the mail.
2. Perform all the changes
3. Sort outbound mail by email address and count the number of messages to each user.
4. Send one email to each user of this form:
Dear :
We are about to reorganize Bugzilla according to . This will tentatively happen on (this date is subject to change in response to natural disasters such as rock slides [1][2][3]).
We’ve calculated that you would receive approximately messages. You can configure your mail preferences at /userprefs.cgi?tab=email
We generally recommend that you not CC yourself to hundreds of bugs as doing so could result in large amounts of bugmail as indicated above.
Further, we request that you not take ownership of many bugs without fixing them. Instead, it’s generally recommended that you configure a watch list.
[OPTIONAL. PLEASE IMPLEMENT.]
In order to aid you, we’ve added a row to “but not when (overrides above):” in mail prefs for “The bug is not open (RESOLVED/VERIFIED/CLOSED).” For people with default mail settings we’ve checked this for you automatically.
[-]
[OPTIONAL. NOT RECOMMENDED. PLEASE DO NOT INCLUDE. IT TRAINS PEOPLE NOT TO DO THE RIGHT THING.]
If you don’t respond to this message, we’ll temporarily suppress all bugmail to your account before performing the reorganization.
[-]
[1] http://weblogs.mozillazine.org/gerv/archives/2008/07/bugzilla_reorg_date_and_time.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=448604
[3] http://forums.mozillazine.org/viewtopic.php?p=4041975#p4041975
Note: it’s possible (not very hard) to backup the email prefs table and then use a simple query to set users to defaults (but exclude people, e.g. me!)
@timeless:
> If someone is getting a lot of email from Bugzilla and they don’t like it, then they did something wrong
In “normal” mode I agree. Don’t subscribe to 30 mailing lists if you can’t handle the static flow of incoming mail. The stress is on “static flow” here.
> We generally recommend that you not CC yourself to hundreds of bugs as doing so could result in large amounts of bugmail as indicated above.
But we’re talking about an extraordinary situation here. One day lots of email, after that back to normal mode.
So if the amount of bugmail normally can be handled perfectly by the user then I don’t see a reason to say “change your settings that work fine for you because on one day I will bomb you with hundreds of messages, after that day your old settings would work fine again”. I’m actually happy that some people are subscribed to bug reports and communicate in Maemo Bugzilla. I’m afraid of bad side effects and less people being active if I don’t disable bugmail for reorg.
Moving a bug report from A to B might be an interesting piece of information, it’s not interesting anymore if you receive hundreds. However it is not an important piece of information to the reporter or watcher, because it does not change anything about the validity or state of the bug. It’s only important to the assignee. And in reality we don’t have that many real assignees reading Maemo bugmail at all.