Tuesday, November 25, 2008

Why users don't bother to file bug reports

This has to be the saddest bug I have ever seen. Unfortunately, I see this type of response all too often, where the user, despite having a perfectly readable stack trace, dump or error message, is expected to either a) prove to the developers that the problem still exists in the latest nightly build or b) provide a reproducible test case.

Running the latest nightly build may be trivial for client software, but for server software running on busy, production servers, this is impractical and difficult, if not impossible. Furthermore, in a production environment, reproducibility is not an easy feat, as conditions are never the same, and accurately reproducing the load of hundreds of users is far from scientific.

Need more examples of saddness? Here's another one. It's a MySQL bug about corruption on a storage engine. This one is particularly bad, as the developers keep insisting on trying to reproduce the problem with various versions, despite several users (myself included) confirming the problem across many versions.

Of course, Eclipse servers are affected by both of those bugs -- Apache won't gracefully restart because of the PHP bug under certain conditions and Bugzilla searches fail because of a storage engine issues.

But wait - it gets even sadder. Here is how the above PHP bug is closed (comment by the reporter) :
Whatever. If you do not want bug reports, I will not post any. I thought
you welcome help and want to improve the product but it seems you care
only about having less work. Forget it. Let this bug be.

IMHO, that a fair statement.

The MySQL bug is closed with this automated message:
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

I understand that the developers' time is precious and that good bug reports are required, but users are not intimate with the source code, and often cannot easily provide more than a crash dump or an error message. That doesn't mean there is not a problem with the code, so relying on the user to do all the heavy lifting seems quite unfair, and a great way to convince your users to not report bugs.

Monday, November 24, 2008

Eclipse servers out and about last weekend

After months of stellar uptime, the Eclipse servers were acting up last weekend. As it turns out, our primary backend server became so busy doing file operations that its response time was measured in minutes. For all intents and purposes, consider a load of "10.00" to be somewhat high. Here is 'fred', with load averages in the 40's whereas its usual load is about 5.00 :

On our dev/download cluster, node 5 had an interesting day Saturday, slowly crawling up to a barely responsive 331.90:

On Sunday, the same node was pretty much dead all day (no blue line at all). At some point it did manage to resurface, and report a load average of 1932.61. I had never seen such a number on a Linux server.

Oh well, so much for perfect uptime.

Friday, November 21, 2008

Mylyn: Indispensable

I have been using Mylyn heavily for about a year now. I hadn't realized how much it has embedded itself into my work habits. It was just how I did my job and I never paid attention to how much I was using it. Then my laptop crapped out. The machine was fine but the screen was dead and so it had to go to the repair shop. That turned into a month long ordeal. The catch was that it was supposed to take about a week so I didn't bother to set Mylyn back up on the interim machine, thinking it would just take too long to rebuild all of my queries (I have a lot because I work on so many internal and external projects). After the saga of laptop repair (non-repair really) had passed its second week I started to really feel the pain of Mylyn withdrawal. I was jonesing. What was going on with all those open bugs?! I was reduced to reading emails to see what had been updated, I couldn't easily follow whole threads... The horror.

My laptop is back now. I was able to catch up on all the stuff I missed. Nice little arrows and triangles showing me what had changed since I last reviewed my bugs. Notifications popping up in the lower corner of my screen when a change occurs. Ah.

The bugs interface would be great if that's all there were to the tool. But with the change sets management, file hiding, etc, I don't think I can live without it any more. It's the first thing I install on any

Thanks Mylyn team!

Monday, November 17, 2008

Portal Updates

We've been working on the Portal of late, adding features people have been asking for. Here are a couple:

  • Projects have been asking for the ability to inherit their meta-data from projects higher up the chain so that they don't need to maintain meta-data for all sub-projects. As bug 198541 and the Standardized Groups initiative progress this will be more helpful: components don't need to have meta-data filled in. So Bjorn and I added simple meta-data inheritance. If you work on the technology.foo project and you want to inherit the meta-data from the technology project you simply add the 'inherit' key and the accessor classes we use for all of the data access will simply walk up the tree until it finds the first level that does not inherit. Additional features may come as we see how this works for people. Here's how simple it is:

  • Required fields now show a red asterisk so that you can tell which fields they are before the form is submitted. This should improve usability of some of the forms substantially. See the image above for an example.

Friday, November 14, 2008

Privacy in open communities?

I just finished reading Doug's latest blog post, which refers to the qemu mailing list archives. We maintain mail archives at Eclipse too, and I'm always interested in comparing notes with other sites.

Beyond all the similarities between their archives and ours, I was surprised to see a link to "download the archives in mbox format."

The mbox file is raw, and reveals email address without obfuscation. It also reveals the IP addresses used to send email (which, in turn, may reveal your geographical location), and, if you're behind a NAT firewall, the mail headers often reveal internal IP addresses too.

Without being overly paranoid, I'm not sure that kind of 'private' information really needs to be out in the open. Putting the raw mbox file up for download is not something we do here at Eclipse.

While I occasionally get asked for the mbox file(s) for Eclipse mail archives, my answer is always 'no'. People are welcome to scrape the 'clean' HTML archives from our website. Sure, it may make research and analysis a bit more difficult, but I feel very strongly about protecting the Eclipse community's email addresses from SPAM harvesters.

Thursday, November 13, 2008

Adobe contributes full translations for Eclipse 3.4 in 6 languages

Yesterday was a happy day for Eclipse users around the globe: our friends at Adobe have given the full translations for Eclipse 3.4 to the Babel project, in French, German, Japanese, Chinese (Simplified and Traditional) and Korean. See bug 254964.

It will take a bit of time for this contribution to work its way through the Eclipse IP process, but it will be imported into the Babel server shortly and available on the Babel download page.

Thanks, Adobe!

Edited: 'around the globe' sounds better than 'across the globe'

Thursday, November 06, 2008

20 Terabytes!

Eclipse.org servers have sent over 20 TB to the Internet in October. This is the first time we break the 20 TB barrier in a regular, non-release-train month. This means we were at peak bandwidth for most of the time (except on weekends).

It's interesting to know that Eclipse.org servers don't generally go under 40 Mbps of sustained traffic, even on weekends.

Wednesday, November 05, 2008

i18n: are you doing it properly?

Babel's fearless leader and Eclipse globalization guru Kit Lo put together a pseudo translation language pack, and it's available for download. Essentially, it takes all your externalized strings and prefixes them with 'eclipsennnnn:'

The Babel Pseudo Translations Language Packs can help:
  • identify hard-coded strings; a string is hard-coded if it does not have the special prefix
  • identify layout problems because of added string length; for example, after adding "eclipse123456:" to "OK", a button label may be truncated
  • identify the component the string is coming from; is the string from Eclipse Platform or from my component?
  • locate the file containing the string; there are probably a dozen copies of the strings "File" or "OK". If you want to locate a particular one to fix the translation, you just have to look up the prefix number from an index file.

The pseudo translation may help you internationalize/globalize your Eclipse plugins correctly.