Tuesday, May 30, 2006

Phoenix activity

Now that the MySQL dust has settled, I've had a bit more time to invest in Phoenix - the Eclipse project that covers our website. Here's what we're up to:

Bigger Fonts: Do you think that our site's font is too small? Stanimir has been kind enough to post a patch which makes our font bigger and more scalable. Read about it in the bug, test it on our sandbox (links in the bug) and feel free to comment by including your browser/OS version, screen resolution and font DPI setting with your comments.

Multi-lingual content: Being French Canadian, I'm the first to admit that there's not enough non-English content on the Eclipse.org website, and many of you agree with me. While we try to find a strategy to make this better, we do occasionally post links to non-English sites on our homepage. I think a link to a [German | French | Italian etc.] page on an English website is strange usability (not because of the foreign characters, but because, from an English page, I'm sent to a page that I cannot read) so in bug 143449 I suggest that we either remove the links to non-English pages (yuck) or add a language identifier next to the links (yay). Of course the better solution would be to have a home for non-English content (fr.eclipse.org, de.eclipse.org, etc..) but in the interim ... what are your toughts?

Wiki vs. website: In bug 125497, Bjorn suggests the Wiki pages should look identical to the website. I think the Wiki and the Website are two different things. So, Bjorn and I need your input: what do you think about this?

These three issues are only the tip of the iceberg. Want to help us make a better website? Have a look at the Phoenix Bugs and the Website Bugs and contribute what you can.



Wednesday, May 24, 2006

Bugzilla replacement?

I was doing some bug triage today, and I kept stumbling on bugs that involve Bugzilla itself - enhancements, bugs, feature requests, you name it. Then I ran a query to list all the bugs in the Bugzilla component. Seems there are a number of ways Bugzilla could be improved, but it also brings up this question: is Bugzilla still the best tool we can use? Or perhaps should we stop using a vanilla Bugzilla, and simply customize it to meet Eclipse's needs. Or better yet, perhaps Bugzilla can become a part of Project Phoenix, where we start tackling the Bugzilla enhancements and bugs ourselves, and then submit the code patches to the Bugzilla committers so that they merge them into the next Bugzilla release.

Mike Milinkovich sums it up pretty good here. What do you think? Feel free to post comments here in my blog, or in the bug. Or better yet, if you've always wanted to contribute to Eclipse but felt you're not the Java guru you could be, hacking the Bugzilla issues that committers consider important would certainly be A Good Thing :)

Friday, May 05, 2006

New toys for committers

The Foundation has been doing its best to provide its beloved committers with the tools they need to get their job done [except for a stable database, which seems like an impossible task for us]. Today, our fearless leader Mike approved the purchase of an additional server for project Virtual Servers.

Although larger projects are often backed by large corporations, the smaller projects are often not as fortunate, and lack the resources needed to implement and run a build and test infrastructure. Some time ago, we were handing out Virtual Servers for smaller projects - essentially, dedicated server resources, with a direct connection to the eclipse.org cluster, that can be used to run builds, produce tests, display performance results, and all that fun stuff. Several projects seized the opportunity: CDT, EMFT, AJDT, ECF and a few others. In fact, these VServers were so popular that we quickly exhausted the few slots we had made available.

So an HP Proliant DL360 is on its way, equipped with 4 GB of RAM and a couple of 300GB SCSI disks. These little boxes don't stand a chance in the eclipse.org cluster, but pack a good punch and make great build/test machines and small web servers. New VServers will be available soon for our projects, and Phoenix will likely be getting one.

If these new toys help our committers in anyway, it just has to be money well spent! ;)

Wiki for everyone - Part II

It finally happened. The Eclipse Wiki is now open for edits to any Eclipse Bugzilla registered user. This will allow anyone in the community to contribute content at any level.

We tied the Wiki to Bugzilla because we know how painful it is to maintain usernames and passwords for a bizillion sites, and we didn't want to make things worse by adding Yet Another Authentication. A Bugzilla plugin for MediaWiki was non-existent (from what we could tell) so we had to write one up.

It was quite simple, actually - MediaWiki allows for authentication plugins, and we were already using an LDAP plugin to allow committers to login to Wiki using their committer id. We simply hacked a Bugzilla plugin to do what we needed.

In the spirit of giving back, I'll be submitting the source to MediaWiki and to Mozilla as it could be useful to others, and I'll post the source on a Wiki page.

Wednesday, May 03, 2006

The OpenSource of yesteryear

The year was 1995: 28.8K modems, 14" screens, Pentium 166's and no Google. Java was only a beverage, and Windows 3.1 ruled the desktop.

I was introduced to the concept of Open Source when I wanted to install Linux. Everyone (who knew) was talking about Slackware, and how great it was. I have fond memories of downloading root and boot disks, reading about the various packages, and doing the installation, only to realize I had picked the wrong packages (there were no dependency checks) or the wrong kernel. I vaguely remember restaring the installation process several times as it was easier to do so than to attempt to install/remove other packages (I was new to this Linux thing, right?). Once I reached a level of satisfaction, I realized my network card wasn't supported by the kernel - so off we go, fetching the latest kernel, compile, install, screw up, repeat.

After a few long nights, I had an NCSA http server up and running, serving web pages on my local 10Mb network. I didn't have to pay a dime for all this, I could look at the source code, and best of all, I was in control. It was great.

Of course, the documentation wasn't so great - neither for Slackware, the Linux kernel, nor for the httpd server. Tutorials were called "How-Tos" back then, and they were often severely out of date. The websites for all those projects were crude and plain at best, and forget about web forums - a bunch of IRCers were just waiting for the right chance to confuse you even more by actually helping you out.

But that was yesteryear's Open Source. Today, Open Source is everywhere, and it's a much different world. Or is it?

Were you introduced to the Open Source world with Eclipse? Tell me your story!

Tuesday, May 02, 2006

MySQL oddities

Some of you who use our site 22 hours/day may have noticed we've been having some database problems for the last couple of weeks. We have two MySQL servers: a master and a replicated slave (well, we used to, anyway). The fault-tolerance aspect of the replication is nice to have, and allows us to get a performance advantage by shifting plenty of SELECT queries to the slave (Bugzilla supports this and benefits tremendously from it, as does our website and search engine).

For the past few weeks, after about 3 days of good service, the Master seems to just stop processing queries. The queries silently queue up until our connection limit is hit. The database server itself responds well; it just doesn't do anything. No logged info, no error message, nothing. So far, no operational parameter seems out-of-place, except one query in the SHOW PROCESSLIST that has a state of *** DEAD ***. We restart the MySQL server and we're good for another few days, except now our slave is out-of-sync.

We went looking in the MySQL docs for that *** DEAD *** state and came up empty handed. Matt downloaded our version's source and started poking around, and found the only instance of the string:

sql_show.cc
#if !defined(DONT_USE_THR_ALARM) && ! defined(SCO)
if (pthread_kill(tmp->real_id,0))
tmp->proc_info="*** DEAD ***"; // This shouldn't happen
#endif

So it looks as if what shouldn't happen happens, except we don't know why and how to fix it. Not being a C++ guru I don't dare look at more code that the above snippet.

A few folks have suggested simply restarting the MySQL server every day. "Lots of sites employ the practice of restarting services regularly", I hear. I dunno, but it sounds Windows-ish to me. Our setup has been working flawlessly for a year without requiring this type of action, so what happened that we'd need that now?

At any rate, the kind folks at Intel have offered to help. If you want to help us work on this issue, you can check out the thread on the mysql forums.

Monday, May 01, 2006

Wiki for everyone

When we opened up the Eclipse Project Wiki at http://wiki.eclipse.org/wiki/ , we limited editing to Eclipse committers. As per bug 118245, we've hacked the authentication mechanism to allow Eclipse Bugzilla registered users to edit the Wiki. It's not live yet; we're testing it out to see if it works.

One challenge we had was hacking the Bugzilla login name (essentially, your e-mail address) to map it to a SPAM-safe login name for Wiki.

If you have an Eclipse Bugzilla account, go ahead and log in to the sandbox wiki; make sure you can edit the pages, save your preferences, add pages to your watch list and all that Wiki stuff.

This change should allow the community as a whole to contribute to the Project Wiki, while not requiring you to remember Yet Another Username And Password.