Archive for the ‘meego’ Category

Maemo, MeeGo, Mer, Tizen: Short statūs

Tuesday, January 3rd, 2012

While the official Maemo platform (led by Nokia) is not actively developed anymore, some 3rd party Extras and the Maemo Community Updates project (which welcomes helping hands) are quite alive.
MeeGo never managed to fulfil its own expectations with regard to openness and transparency and is also more or less dead.
Tizen (MeeGo’s successor) is still vaporware plus membership is mostly invite-only while I prefer transparency.

Mer LogoWhat is left and to recommend in this area is Mer, a community-driven project based on MeeGo with real open governance and trustworthy maintainers that know how to communicate.

Consequently I have removed my admin flag for MeeGo’s bugtracker (it feels unmaintained anyway) and unsubscribed from nearly all MeeGo and Tizen mailing lists.
I will continue to stick around in the Maemo and Mer communities (mailing lists, IRC, bugtrackers) as they currently feel like the places to be. Cheers!

MeeGo QA and RE stuff I’d like to understand.

Tuesday, June 21st, 2011

About some stuff that I’ve recently tried to find out in MeeGo.

Quality Assurance

  • “Risk level” and “UX status” field in MeeGo Bugzilla was not documented anywhere – Bryan asked before, I asked again, and in the end “Risk Level” got removed. Yay.
  • Initially I questioned the “Triaged by” field especially because it was introduced without any public discussion of its usefulness or announcement of its introduction at least. I can accept its existence but I would still like to know where the data will actually be used.
  • Products in Bugzilla have been created without a default assignee to take care. I consider this a problem (“sort out first who will take care” as we do in GNOME Bugzilla) while others didn’t (“give testers the possibility to report bugs”).
  • On a very related note there is an account named “need-triage@meego.com” (previously called “nobody@meego.com”) that bug reports can be assigned to. Asking about its usage I got told that this is “a critical indicator for project management” that resources are missing and also that “this should be fixed at project management level”. So I asked if efforts have been made to fix this on the project management level and if the data (tickets with this assignee) is actually used but have not received answers yet.
    Apart from the inconsistent naming (the domain “meego.bugs” looks more appropriate as virtual accounts of that format already exist in Bugzilla) this might now becoming the rotting /dev/null for all the reports that initially received a wrong assignee.
    As per June 9th, 38 non-closed tickets have the assignee need-triage@meego.com. Between 2011-03-04 and 2011-06-05 there have been exactly 3 tickets whose assignee was changed from need-triage@meego.com to somebody else, all of them in the Compliance product in one go. To me it is obvious that something does not work well. As opinions differ I asked for an interpretation of these numbers and am still waiting.
  • Plans for a Bugzilla structure enhancement that were described in a BoF session at MeeGo conference. Still waiting for any documentation to review it but I might not have a chance as the bug report already has READYFORINTEGRATION status.
  • Unhappy of restricting access to complete bug reports just because of one inappropriate comment added (for the definition of inappropriate check the wiki). Plus nearly always people restrict access without explaining why. I might enable marking only single comments as private soon.

Release Engineering

Update: Received responses to my RE questions now.

It’s likely that this list wasn’t complete. I now might be too keen on documenting processes (that’s the “information vampire” pattern as Carsten calls it). Friends and colleagues providing their impressions and feedback by larting me in a friendly way is appreciated.

I have not used the word “transparency” in this posting but you can probably insert it at any place.

MeeGo conference San Francisco

Thursday, May 26th, 2011

I went to San Francisco (US&A) to play Ping-Pong with Chris (I also recommend him as a tour guide – he knows the city). At the same time a conference took place.

At the weekend’s preconference I discussed MeeGo L10N with Margie. I cleaned up the wiki before, but still there is enough to still sort out:

The most important talk from my point of view was Carsten‘s “Transparency, inclusion and meritocracy in MeeGo: Theory and practice” showing some of the transparency problems that MeeGo has not only after one of the two bigger companies involved announced a change in direction.

There was also a Release Engineering BoF. A great opportunity as so far I had been totally unsuccessful in understanding how this works in MeeGo. This has not improved yet though. It looks like decisions are made completely in private in the offices of one company (Intel) instead of the public (internet). Other issues: The Submit Request account process is not documented – how to contribute from a new company? You’d expect something other than dead silence here. But it was agreed on that the CCB (Change Control Board) process for MeeGo 1.2 was completely invisible and “crap”. (Dawn might now complain about my use of language, but this was the wording used by those running the session.)

But the original reason to come here was MeeGo’s Error Management (EM) and Quality Assurance (QA). I outlined some EM and QA issues to discuss on the meego-qa mailing list before the conference took place. See the summary of this BoF. Hoping to see further discussions of issues in the public, as agreed upon.
Iekku and I gave a talk on the basics of bug handling. Plus Eric and Stephen presented some cute Bugzilla extensions but I leave it to them to blog and email about it (a good task as they have been too silent and invisible so far).

MeeGo bits and bugs

Wednesday, April 20th, 2011

MeeGo

Haven’t blogged for a while on MeeGo related stuff, probably because GNOME was way more crucial in the last weeks.

And on an unrelated note: The MeeGo QA Dashboard beta looks pretty neat.

My MeeGo bugtriaging experience so far

Wednesday, December 8th, 2010

But it happened that it was early October and that I felt like diving into MeeGo bugtriaging. After some public whining, Carsten (who’s always a huge help) and Dawn were kind enough to point out the existence of the meego-qa mailing list. I subscribed.

At that time there also was a wikipage with a list of names (“Contact the first person in the team” without any hints how to) and an IRC channel (#meego-bugs on Freenode) with one or two people but not much feedback.

Being in a JFDI mood I moved some wikipages (related information was split under wiki.meego.com/Quality and wiki.meego.com/Bugzilla) and asked some questions on the mailing list. Some have been answered, others haven’t.
I sometimes wondered if either QA engineers don’t know answers or if QA management prefers to remain silent to avoid making decisions, or if a few people just consider documenting their workflows and communicating what they are working on in public a waste of time.

What has changed:
I set up a triage guide.
The bugtriage meetings are now on IRC, in public.
The wikipage looks way better, things have become more transparent in general, and the IRC channel constantly has some people lurking around.
On a related note, the QA talk at MeeGo conference was particularly helpful to get the broader picture of all the MeeGo QA tasks and to realize that bugtriaging is just a small part of the picture.

Next on my list is to start collecting stock answers (like in Maemo) which requires help from triagers having specific knowledge. However, as I like to sort them by Bugzilla products, I am a bit reluctant as Eric said that the classification and product structure in MeeGo Bugzilla will probably change a bit after deploying Bugzilla 3.6.

Still there is enough to do and I am not happy with the current “openness” state. Remaining unanswered questions that I cannot “solve” myself as I miss information:

  • Who “defined” who became/is a triage team lead (=first person in each of the triager lists)? Were there elections, was it a decision of the companies involved, or was it meritocratic?
  • Why should I add my name to the triager lists as I could also triage without adding my name to a wikipage? What obligations are connected to adding my name?
  • What is concretely the job of “triage team leads” in contrast to “normal” team members? Why was a hierarchy considered as needed and introduced?
  • Documented permission requirements are missing. For example feature requests in bugs.meego.com cannot be fully edited without permissions (e.g. “Summary” line is non-editable). I don’t want to discuss the usefulness that I cannot fix typos in summaries because of that, but I’d like to see this documented in the wiki at least as I might not be the only person who was initially confused by it. I can’t document it myself as I don’t know the exact reasons behind this.
  • What does “Error Manager rights on MeeGo Bugzilla” actually mean? Filed a bug report, no progress yet. Feel free to vote.
  • Missing policy when to completely block access to a report and when to just mark specific comments as private – See my posting.
  • Difference and handling of “enhancement” severity vs. “MeeGo Features” classification and documenting the explanation in the wiki.
  • There is a list of code customizations for MeeGo Bugzilla. Are the source code patches somewhere available? Have they been upstreamed or submitted as patches in bugzilla.mozilla.org (in case that it makes sense)? If not, why not, and is it planned to do so?
  • Where to handle MeeGo Extras/Surrounds apps bug reports? – See posting here.

bugs.maemo.org updated to 3.4

Wednesday, December 1st, 2010

As some might have noticed, bugs.maemo.org was upgraded from ancient version 2.22 to 3.4 last week. This means we now have a version running that is maintained upstream, a design that fits to the rest of maemo.org, less noisy comments, a frontpage that now states “This is a community issue tracker, sponsored by Nokia, not a Nokia communication channel”, and less complexity by e.g. hiding fields that normal users don’t ever need when filing a report. Plus we are not at the bottom of LPSolit’s list of Bugzilla installations anymore. ;-)

All kudos goes to Karsten Bräckelmann for lots of work (like applying the maemo.org wide theme, turning some image files into pure CSS, and tracking down ugly database transition issues), David King for continuing with finetuning and fixing missing pieces, and Ferenc Szekely for testing and deploying!

Today I finished updating my little Greasemonkey triage helper script for maemo.org Bugzilla so it should be functional again.

I also wrote an initial Greasemonkey triage helper script for meego.com Bugzilla that provides some common one-click stock answers and will display the email addresses of commenters and reporters by default (I like to spot immediately if a commenter has a corporate background).

(On a side note, yes, Mozilla Jetpack extensions are of course the future and to supersede Greasemonkey, like Matěj’s bugzilla-triage-scripts. That’s on the ever-growing to-do list.)

MeeGo Conference 2010

Sunday, November 21st, 2010

The enthusiasm at this conference was pretty impressive. It was probably the right boost for the MeeGo project at the right time as engineers of involved companies could get to know each other and hopefully now also understand a bit better the needs and expectations of the community with regard to openness. At least some of them. ;-)

MeeGo

(Compared to other conferences) I went to a lot of talks in order to get a better understanding of MeeGo.

After the initial keynotes and Dawn Foster’s “State of the community” talk I went to Eric & Stephen’s “Error management Tools and Processes” talk which helped realizing what we are after in the field of error management.

My second day started with Quim’s Marketing session and Dave Neary’s enjoyable “Community Anti-Patterns” (many of them already well known from Maemo). Didn’t manage to attend Stskeeps’ “MeeGo on N900″ talk because of some chats in front of the venue and in the entrance hall. Continued with the insightful “MeeGo L10N/I18N upstream”, “Community Metrics” and “Community Application support”.

The “MeeGo Quality Approach” talk by Veli-Pekka Valula and May Xie was helpful to understand the complexity of QA and why help in improving the bug management is welcome. Also a nice opportunity to meet the Intel QA folks from the mailing list in person!

My own BoF session “Handling bug reports in bugs.meego.com” was on Wednesday morning right after the great Guinness party the evening before. Hence I incorrectly expected not to see many people around (and me being sleepy and tired) but according to feedback it went well and I think we had fun (well, I had!).
When I created my slides I had Josh Berkus’ “How to Prevent Community: Making Sure Your Pond Stays Small” in mind but I kept sticking to issues specific to bug management that could be done better in Maemo and MeeGo. Right now there are mostly bug reports by people with a technical background in the bugtracker but once MeeGo becomes more popular we will have to deal with user reports with different qualities and points of view.
I hope the video will soon be available somewhere here.

All in all I had a good time in Dublin that left me in a positive mood regarding the future of MeeGo.