So it’s official: We’ve decided at the GNOME.asia hackfest that we’re going to postpone GNOME 3.0 a bit. As written, one of the reasons is that the amount of remaining issues is simply too high.
While it’s disappointing to change plans that late after spending so much energy on pushing this on time, it’s probably still better than having a quite buggy release. Looking forward to having a great GNOME 3.0 in September…
After a great flight I arrived in sunny Bangalore yesterday and am going to spend some days at the Intel office and at Dayananda Sagar Institutions with over a dozen of brave, friendly and good-looking folks to work on GNOME3 that is going to be released in a week. The coffee and food is great, however I miss access to IRC (but webclients help).
And we’ll also have the GNOME.Asia conference at the weekend with more than a thousand attendants.
We kicked off the long first hackfest day by introducing each other and listing the plans what to work on. Some of us then discussed the gnome3.org website and marketing related stuff, the rest of the release-team and desrt were mostly hacking, and many others continued to plan this weekend’s conference.
A short summary of what I did today:
The results can be seen here.
Plan for tomorrow is some smaller Bugzilla reorg cleanups and start working on the presentations slides for the random-topic conference talks that I proposed (and which got accepted).
The GNOME release-team met yesterday and reviewed the blocker reports in GNOME Bugzilla by splitting them into “must-fix”, “should-fix” and “nice-to-have” categories. These are the results.
Data taken from Bugzilla (bug reports with GNOME Target field set).
Data taken from Bugzilla (bug reports with “[gnome3-important]” whiteboard entry).
As usual I posted a short activity summary for 2010.
Also quickly wrote up the GNOME Q4 quarterly report for the Bugsquad.
Posted a first GNOME 3.0 blocker report (based on GNOME Bugzilla data). Planning to do this once per week now. Feedback welcome whether it’s helpful to see what’s still left on the way.
Created a wikipage to get the Evolution user documentation rewrite better documented and organized as I am afraid that at some point the complexity of this task might demotivate all involved folks (Phil Bull, April Gonzales, Barbara Tobias and me). Asked Novell to relicense the old manual so we can potentially reuse some good parts. Work is ongoing.
The Google Code-In contest has just ended today. It’s been a pleasure and I’d like to thank all students and mentors for participating. Hope we all had some fun together (I had), though we did not have that many tasks available (I can’t provide exact numbers as Google now just displays “This page is inactive at this time.” for the list of tasks, but comparing for example to KDE we had maybe half of their tasks). Also see my previous post for stuff that has been achieved.
I am very interested in feedback from non-mentors that considered adding a task but didn’t, mentors, and students to see what we can improve (e.g. in our wiki) for a potential next time – feel free to send me an email or add a comment to this blog entry.
I’m spending this week in Helsinki. Feel free to ping me for an evening beer.
And for more (and way cheaper) beers there’s also the GNOME Python hackfest next week (not that I suddenly started hacking Python, just that I should be in the same town), and FOSDEM in four weeks. See you around?
Same procedure as every year: My private soundtrack for 2010, in alphabetic order. (And the same usual disclaimer: Explicit lyrics and/or video content – it’s about the music.)
Phoenix: 1901 (Blogotheque version) / M.I.A.: Born free / Robyn: Dancing on my own / My Heart Belongs To Cecilia Winter: Eighteen / Die Antwoord: Enter the Ninja / Unkle feat. Sleepy Sun: Follow Me Down / Metric: Gimme Sympathy / Martin Solveig feat. Dragonette: Hello / The Roots: How I Got Over / Sophie Hunger: My Personal Religion / FM Belfast: Par avion / Kanye West: Runaway / Lady Gaga feat. Beyonce: Telephone / How To Destroy Angels: The Space in Between / School of Seven Bells: Windstorm
Two weeks ago I attended the GNOME Development Documentation and Tools Hackfest. Since then I’ve been working a bit on Mallard documentation for Evolution. It’s a complex task and I am happy that Barbara Tobias has offered her help. You can follow the development on gitorious.org. To take a look, clone it and run “yelp .” in the checkout directory.
Ignoring my own plan (something I already expected to happen when writing it up) I spent time thinking of structure and categorization of help topics and turned my “expressionist dance” drawing into a small but still confusing inkscape graphic that I’ve been enhancing over the last days while going through the old manual (the numbers in the picture refer to sections in the old manual):
Interesting sources for stuff to cover could be the FAQ, the old documentation (though the license is incompatible), the recent posts on the user mailing list, and recent bug reports that have been closed as INVALID (often because of misconfiguration issues or support questions instead of real software bugs).
I also hope to turn finishing some stub help pages into Google Code-In tasks. Yesterday I created the first task for documenting the search functionalities.
Help is welcome if you are brave enough to tame the beast.
This is a short status report at half-time of Google Code-In 2010/11 contest (3 weeks have passed and another 4 weeks to go until January 10th).
Most of the students do an awesome job! Just to highlight some of the tasks that have been finished:
Currently 84 tasks are finished, 12 ongoing, and 22 available for students to work on. And we still accept tasks! Click here if you want to mentor ideas that you have, or click here if you want to take part as a student!
Decided to upgrade one of my machines this weekend.
While Fedora’s PreUpgrade is intelligent enough to check the free diskspace on / before downloading the new packages (at least according to the terminal output, bug 649399 states differently) it does not try to estimate if there will still be enough free space to actually extract and install them and will just cancel the process after the reboot (“You need more space on the following file systems: 224 M on /”, whatever unit “M” is meant to be). A bit late.
On / suspect areas to manually clean up are /tmp, /var/cache/yum (some data from older versions around) and /var/cache in general. Biggest packages that could be temporarily uninstalled were webkitgtk-debuginfo, gcc-debuginfo, openoffice.org and eclipse (not needed this time, but maybe next time?).
And apart from quite some typos in PreUpgrade strings (filed a bug) I of course also ran into probably all Evolution bugs that I could:
But apart from that I think I’m fine.
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:
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.)
