Thursday, March 22, 2007

REMIND and LATER: can we just delete them and move on?

With Alex' latest post on EZ he makes it plenty clear that REMIND and LATER are not valid bug resolutions.

I opened bug 178923 requesting their removal. Go vote, vent, and comment, so we can get rid of them once and for all.

Friday, March 16, 2007

New major Bugzilla release on the horizon

Bugzilla 3.0, expected to be released in early April, is sure to be a crowd pleaser with a host of new features our Committers have been requesting. Here are some highlights from the Release Notes:

- Custom Fields. The IP team will appreciate this flexibility on IPZilla, as it runs a vanilla Bugzilla installtion as well.

- Shared Saved Searches.

- Custom Resolutions. No longer limited to fixed, wontfix, worksforme, remind, later and invalid, we'll be able to add RESOLVED/NEVER as Alex dearly loves. Perhaps even RESOLVED/FINALLY and RESOLVED/CANTBEARSED :-) Joking aside, we might want to consider removing LATER and REMIND, as these are arguably not valid resolutions. You can read up and comment on bug 177497.

- Edit Components in your own product. This functionality is available as a separate Committer Tool, but native support within Bugzilla is much better.

- Default CC list for components. Yay.

Friday, March 09, 2007

EclipseCON by the numbers

As is tradition, EclipseCON comes to a close with a cool "EclipseCON by the numbers" presentation, which is more humourous in nature than it is scientific. EclipseZone posted the stats yesterday, and I have some numbers of my own -- these numbers show the impact of a popular event on our website:

Number of HTML pages sent by www.eclipse.org each day of the conference: 1.4 million
... % increase relative to daily normal: 100

Number of files sent by download.eclipse.org each day of the conference: 4.6 million
... % increase relative to daily normal: 53

Number of wiki pages viewed each day during the conference: 125,000
... % increase relative to daily normal: 79

Number of disgruntled Foundation IT managers who couldn't attend: 1
... but it was for a good cause. Fortunately for me, next year's conference is later in March :-)

Thursday, March 08, 2007

Unintended consequences: local build servers

When projects run a build, I had always thought it would be much more efficient if the build servers were physically on the same LAN as Eclipse CVS and downloads, instead of pulling/pushing code over the Internet. After all, bandwidth isn't free. Well, that turned out to be true, as several projects now use some of our server infrastructure to run their builds. We do save on bandwidth. Now for the unintended consequences:

a) local builds are much, much faster thanks to gigabit networks and quad-cpu monster servers.
b) faster builds means teams can "afford" to build more often. Nary a minute goes by where I don't see WTP build something.
c) more builds from powerful monster build servers put more strain on our storage server.

Back in January we had a problem where our storage server would simply give up on life, and we didn't know why. We concluded that when the monster build server sends a few gigabytes of data to an already busy storage server, it gets overwhelmed to the point where it sometimes simply stops serving files. Ouch.

A busy disk shouldn't kill a server, but we have no fix in sight, other than some hacked scripts to monitor and kick what needs to be kicked to avoid a crash. They work great, but the problem isn't fixed per se, so where does that leave us? I thought of two solutions:

a) rearchitect our storage backend to handle massive disk writes. This will require hardware and money, so it won't happen tomorrow.

b) throttle the network for builds. The Internet introduces a natural throttling process, so if the build server talks slower, maybe the storage will have time to write everything down without falling over.

For now I've throttled the build network -- although the server can read files at gigabit speed, it can only write at about 100Mbit/sec. Let's see how that works.

Oh the joys of running servers for a pretty busy site never end...

Sunday, March 04, 2007

PlanetEclipse on Caffeine Overdose

Not to be outdone by last year's EclipseCON, the Planet will be aggregating every 10 minutes while EclipseCON is in full swing. This should help you keep up with all the blogging that will be happening live from Santa Clara.

I can't be at the Party this year (my daughter turns one (already?!) on March 7th and I didn't want to miss that), but I'll be reading about all the excitement happenng in California from our snowy Igloos here in Ottawa - so be sure to blog plenty!

Friday, March 02, 2007

Eclipsepedia gets a facelift

Eclipsepedia (the Eclipse Project Wiki) got a much-needed overhaul yesterday. Updates include using the latest release of MediaWiki, and a look identical to the rest of the www.eclipse.org website. Go check it out!

Props to Matt for getting this done despite everything that needed to be done at the same time -- I could hear no end of cursin' towards CSS.

If you spot anything that looks out of the ordinary, please file a bug against Community/Wiki.

Thursday, March 01, 2007

Do you bloat?

I found Steve's 'the end of an era' blurb an interesting one, where he asks "Oh computing world, where did we bloat out and go wrong?" I'm sure Steve knows the answer: with massive amounts of computing power at our disposal and requirements to deploy rapidly, developers no longer need (or have time) to optimize for efficiency. This is also true about apps deployed to the web, where a web application often needs to scale up to, and perhaps even beyond the number of users it's expected to serve.

Yesterday I witnessed two instances where Bloat Prevailed for a few professional, competent developers I know well. The examples here are simply to illustrate that everyone is "guilty as charged" when it comes to bloat. Hey, I do it too, so let's all poke fun at ourselves as we read this:

Case #1 is the EclipseCON website. I had noticed that the server's load was climbing rapidly -- which is normal, in the days leading up to the event -- but I was worried that the site would crumble come Monday morning. The site, as written, ran swimmingly on a laptop by one person, but could potentially collapse when accessed by dozens (hundreds?) of users simultaneously. After optimizations, the bloat was removed and server load dropped considerably. Crisis avoided - I think we're in good shape for Monday.

Case #2 is with the www.eclipse.org website itself, where bug 175875 suggests that the links in the Phoenix templates become absolute URLs (such as http://www.eclipse.org/legal/), not relative (/legal/), so that the PHP templates can be deployed on other Eclipse websites without modification. It's a great idea, and it seems insignificant enough when you forget that www.eclipse.org often transfers over 20 million pages/month. After a few calculations, I concluded that this change could involve sending an additional 4GB/month to the Internet. It's not that the number is outrageously big, but it's an extra 4 GB travelling on Internet backbones, fiber links on the bottom of oceans, and expensive Cisco routers everywhere. Worst of all, it's 4 GB that doesn't *need* to be there. We all discussed, and we're investigating possible solutions to avoid some bandwidth bloat (at the cost of CPU cycles, of course -- but one needs to choose the lesser evil).

Of course, this blog post isn't meant to mock the EclipseCON site developers, nor Karl who opened bug 175875. We're all guilty, so let's all say it loud and proud: I bloat, you bloat, we bloat. The unfortunate reality of all this is that, in today's computing world, it's all too normal and acceptable to bloat.