Symphonious

I’ve brought home one of the SunBlade 100s from work with the intent of installing Solaris 10 on it and trying to get a grip on the idiosyncrasies of Solaris.  Eventually I hope to be able to put the e250 we have at work to better use and learn enough to actually admin it properly instead of just doing the very minimum possible to get things to work.

Being a programmer by trade, picking up sysadmin skills isn’t exactly the easiest thing in the world so it will be a bit of a journey.  Fortunately I have a basic working knowledge of UNIX and only a few fairly straight forward things to get up and running on the machine.

So, any tips on where to start and sources of knowledge I should be perusing?

Tomorrow night the band will be playing at the Crossroads Christmas Party.  Crossroads is a support group for people with mental and physical disabilities.  The Christmas party is always a heap of fun and the crossroads folk are simply the best audience anyone could ask for.  They dance to every song, sing along anytime they know the words and really show how much they appreciate the music.  It’s definitely very uplifting.to see such joy on people’s faces.   I can’t wait.

A while back I complained that Mozilla didn’t support align on colgroups.  Byron suggested that I should log a bug and his comment suggests that he’d actually searched and found that one hadn’t yet been logged.

I too searched, specifically for the term "colgroup" and out of the 3 or 4 bugs that were returned, none were what I was complaining about.  So I spent the 20 minutes or so that it takes to jump through all the hoops that the Mozilla team want you to jump through to log a bug and gather all the required information, including creating a simple test case etc.  Finally I submit my bug and within five minutes it’s marked as a duplicate of a bug that has been going on and on and on and on forever.  Seriously, it shouldn’t take over two years and hundreds of comments to sort this out.

What really struck me as stupid though was the fact that so much effort had been put into customizing the bug reporting progress to try and limit the number of duplicates that were posted yet noone had stopped to actually check that the search engine was capable of turning up even the most basic of queries without having to jump through hoops and fill out the huge, advanced search form Bugzilla provides (which probably would have turned it up).  I mean, just count the number of times colgroup appears in that bug report.

So at least in my mind, this insignificant little missing feature has highlighted three of the most critical flaws in the open source seems to mostly work:

1. Huge claims are made without being actually backed up.  Mozilla is claimed to be standards compliant yet it clearly doesn’t support HTML 4 and XHTML 1.1 which require align on colgroups.
2. Many eyes mean many arguments.  This bug has hundreds of comments and all useful information is drowned out by them.  Worse, the bug is still open after years of discussion.  The worst part of this is the fact that the whiteboard refers to a comment that essentially says: "fix it yourself or stop asking for it to be fixed".  Regardless of whether you are paid or not, you shouldn’t be expecting users to fix problems in your software - that’s what developers were invented for.  It’s okay to say, we’re not going to fix this now because it’s not high priority and then listen to your users and up the priority if they complain a lot - the problem is when you tell your users to stop providing you feedback about the priority of bugs.  That’s just sticking your head in the sand.  If it’s considered okay to write to commercial vendors advocating they support your favorite OS, it’s okay to write to open source projects advocating they support your favorite features.
3. Developers think like developers.  Users aren’t developers.  If the people who set up that bugzilla instance had taken a moment to think like a user, they would have realized that the best way to avoid duplicate bugs is to have an awesome search engine that would quickly and reliably tell the user if the bug they wanted to submit was a duplicate.  Obviously noone has done this at Mozilla because they went down the road of repeatedly telling the user to search for existing bugs before submitting and no doubt every time a duplicate is reported they swear about the stupid user and put up another sign.

Sure that’s some serious extrapolation but think about your experiences with open source projects and you should be able to think of a wide range of examples of these issues (though it’s not as common to get them all in one example).  Some projects are better than others and a small few avoid all these pitfalls.  These problems aren’t an inherent symptom of open source development, merely common traps for unsuspecting opensource projects.  It’s also worth noting that proprietary development teams can also fall into these traps though they tend to hit different problems more often.

The obvious response to this is that I should jump in and fix the search box, but if I did that I’d firstly have to learn a foreign codebase, then I’d have to spend the next few years in an argument about the issue (see point 2) and in the end, I don’t get any benefit out of it all.  I rarely use Mozilla based browsers anyway, I only found this issue while researching stuff for the product I’m actually paid to develop.

I’ve commented a few times before about how difficult it is to test text manipulation code and most of that is caused by the fact that it’s so hard to comprehensively define all the possible states, user actions and resultant behaviors that are expected.  There’s just way too many different cases that can occur (infinite in fact).  The two hardest areas for most rich text editors are lists and tables (not surprisingly since their really the only complex structure used in text markup).  In order to improve behavior in those areas and avoid any regressions we’ve started specing out the expected behavior.

The first draft for lists contains around 600 expected behaviors (which will map pretty much directly to test cases).  That’s 600 basic things that a user might do to lists within the editor.  It doesn’t include sequential actions either.  It also doesn’t include anything about parsing, serializing or rendering.  Fortunately it’s the weekend, I think I’ll try to focus on something a little simpler - you know, like brain surgery or rocket science….