Fedora 13→14…

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.

Posted in computer, gnome, lang-en | 1 Comment

My MeeGo bugtriaging experience so far

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.

Posted in computer, lang-en, maemo, meego | 1 Comment

bugs.maemo.org updated to 3.4

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.)

Posted in computer, lang-en, maemo, meego | 6 Comments

Google Code-In status

Google Code-In Logo

Google Code-In contest has started on Monday and things are going nicely apart from interpretating contest rules (solved on the gci-discuss mailing list), slowness in task list access (fixed by Google yesterday), and way less email notifications than expected (you have to click the star icon to subscribe to notifications even when you are the mentor of a task).

Big kudos to Lucian Adrian Grijincu for providing lots of useful feedback on how to improve, update and fix the contest documentation on our wiki. I even tricked him into becoming a GCI co-admin for GNOME – Welcome! ;-)

We are looking for more tasks!
We only have about 30 so far but lots of interested students. Tasks can be provided at any time, just go ahead!
If you have anything in mind (e.g. translations) that could become a 2-5 days task for high school students please do become a mentor. Check out the instructions and help a student on her or his trip into the open source world!

Posted in computer, gnome, lang-en | Comments Off on Google Code-In status

MeeGo Conference 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.

Posted in computer, lang-en, maemo, meego | 1 Comment

GNOME accepted for Code-In; Tasks needed!

Google Code-In Logo

Good news: GNOME has been accepted for Google Code-In that starts on Nov 22nd!

Now we need your tasks for students, may they be about Code, Documentation, Outreach, QA, Research, Training, Translation, UI. Please take a moment and think about smaller stuff that needs to be done and could help to make young folks dive into open source.
Check GNOME Community: How to Get Involved for more info how to become a mentor, and feel free to contact me if something is unclear or if you need help. (About the tasks already proposed in our wiki: I plan to migrate them to the project’s task tracker in a few days.)

Posted in computer, gnome, lang-en | 2 Comments

24.10.2010

Schlingensiefs Fünfzigsten angemessen verbracht.

One day you will lose it all

Unser Ziel ist der Tod

Keine Rotweinscheiße.

Posted in lang-de, non-technical, prague | Comments Off on 24.10.2010

Google Code-In: GNOME needs your tasks!

Some might remember Google’s GHOP contest in 2007/08. It will take place again under the name Google Code-In (GCI) from November 2010 to January 2011.

Google Code-In Logo

GCI is a “small sibling” of Google Summer of Code for highschool students (13 to 18 years) and with much smaller tasks in several categories (like documentation, code, translation, UI, etc). The average amount of time to be spent for a task should be about three days. See the GNOME wiki for more info.

GNOME community:
If you have an idea about a possible task, want to guide a student to fulfil it and perhaps also want to get new contributors for your project/area, please read how to write a good task and then go ahead and propose your tasks as GNOME will apply for taking part in this contest.

See you around!

Posted in computer, gnome, lang-en | Comments Off on Google Code-In: GNOME needs your tasks!

Opfer!

Vor einigen Tagen beim Schlendern durch Vršovice wurde ich erheblich verwirrt durch eine Hauswandschmiererei als Kombination deutscher Sprache, aktuell formulierter jugendlicher Missfallensäusserung und einer Schreibschrift, die seit Jahrzehnten nicht mehr gelehrt wird und für die bereits meine werte Mutter zu ihrer Mutter gehen musste um sich den Text vorlesen zu lassen, den ich ihr auf einer Postkarte geschrieben hatte.

Opfer.

Aber irgendwie lieb ich das.

Posted in lang-de, non-technical, prague | 3 Comments

GNOME 2.32 is out.

GNOME 2.32

(Design by Vinicius Depizzol)

It was a hectic day. GNOME 2.32, the last 2.x version, is out now! Big thanks to all the hackers, translators, bugsquadders, documentation writers, artists, marketing folks, ….

Personally I’m proud that our small translation team again managed to have 100% coverage.

The release notes might be a bit boring as most development is focused on GNOME 3.0 (April 2011), and there’s more than quite some work left to make 3.0 the awesome release that we all want to see. And by the way, module proposals period for GNOME 3.0 has started too.

Posted in computer, gnome, lang-en | 1 Comment