Hacking for Christ

Trackbacks and Comments Disabled For Posts Older Than A Month

With a heavy heart, I have just gone through every post I've ever made older than a month, and disabled trackbacks and comments. Given MT's lack of a trackback management interface, deleting dodgy trackbacks takes about 10 times as long per trackback, and I just can't afford to spend that sort of time cleaning up.

The MozillaZine crew are working hard on solutions to the spam problem, but I don't have an ETA, and so I feel I have to take this measure to save my sanity. Until such measures arrive, I will be periodically disabling these features on inactive posts once they get that old.

If anyone wants comments or trackbacks reopened on an old post, please email me and let me know, and I'll do it immediately.

Update: Phil Ringnalda points out that MT does have an identical interface for managing Trackbacks to the one for comments - and it's linked in the left hand bar. So how did I miss it?

1. The "You have a trackback" email doesn't have a link (as the "You have a comment" one does) to view/delete that trackback, which takes you to the list after using it.
2. Deleting a trackback (or comment) from the Edit Entry screen takes you back to the Edit Entry screen, not the full list.
3. I couldn't find my own head if it were handed to me on a plate.

So, I never discovered it. <sigh>. Still, better late than never.

Update 2: The first two comments to my original post also point this out. I really am being dumb today.

XML Inclusions (XInclude)

The W3C's XML Inclusions standard has just reached Proposed Recommendation status.

This document specifies a processing model and syntax for general purpose inclusion. Inclusion is accomplished by merging a number of XML information sets into a single composite infoset. Specification of the XML documents (infosets) to be merged and control over the merging process is expressed in XML-friendly syntax (elements, attributes, URI references).

This seems really like our overlay mechanism, but a bit more complicated. The listed authors are two guys, one at Microsoft and the other at BEA Systems. Does anyone know if any Mozilla people were involved?

Java 1.5 ("Tiger") Released

Java 1.5 has been released for Solaris, Windows and Linux.

This version of the Java language includes support for generic types, autoboxing, enums, printf, varargs, and more in-code metadata. In the referenced article, each feature is introduced by the relevant stanza of a verse written for the occasion; the quality of the scansion clearly demonstrating that while hackers may be like painters, they certainly aren't poets. Stick with the original, lads.

This version of the Java platform now has three possible version numbers - the internal version number "1.5", the generation number, "2" (as in J2SE), and the new version number, "5.0". Laugh as they try and explain what on earth they were thinking.

Trackback Spam :-(

I've just about got a handle on the comment spam. I clear it out, taking about five minutes every day. It's a small price to pay for decent discussion. But now I'm getting trackback spams. And they are 10 times worse.

For a start, MT's Trackback management interface isn't the same as its comment interface. There's no link in the email you get, there's no central list of trackbacks, and once you finally get to the correct entry you have to delete every dodgy trackback individually. And although you can turn off comments globally, you can't turn off trackbacks. It's a per-entry setting, so I'd have to go through all X entries and turn it off for each.

And, to add insult to injury, when you try and create a generic URL which you can paste numbers into, MT complains "Can't delete that way". Why on earth not, you brain-dead piece of software? Grr...

Any solutions, please let me know!

Bugzilla Data Mining (3)

People were asking about the relative magnitudes of movements between products. This is somewhat relevant to the component reorganisation, although we're not planning to do that until after 1.0. Still, here's everything above 100, cleaned up to merge the Phoenix, Firefox and Firebird products.

So some conclusions, then:

• Even accounting for the original creation of Tech Evangelism, loads of TE bugs get misfiled. Hopefully, the new "report a broken site" webtool will help a lot here.
• Three times as many Browser bugs get misfiled in Firefox as Firefox bugs in Browser. This is to be expected - people file it in the product they know.
• Thunderbird hasn't been around long enough to get that much data (it's actually 50 MN->T, 99 T->MN, roughly in line with Firefox).
• The MailNews/Browser split is about even.
• Quite a few bugs are, or have been misfiled in the Bugzilla component. Recently, there's been a big warning on the product selection page; it would be interesting to see if that's made a difference.

More bugzilla.mozilla.org Improvements

As well as the mechanism for automatically resolving some UNCONFIRMED bugs, mentioned in an earlier blogpost, we have some other ideas for trying to improve Bugzilla before the Firefox/Thunderbird 1.0 hurricane hits us.

1. Build a "feedback webtool", like Netscape's, which feeds directly into a newsgroup or forum. This is to try and divert rants, support requests and other non-bugs away from Bugzilla. Asa and Kerz are working on this.

2. Build a "Report a broken site" webtool which aggregates problem URLs and produces lists and reports, rather than having one bug per report. Robert Accettura is doing the hard work for us here.

3. Redesign the b.m.o. front page to include links to these two tools and a better community link. I've done this; it'll go live when the two webtools are online.

4. Redo Bugzilla Helper to be clearer and have less text. Stop accepting bugs in anything other than the latest release.

5. Change the search people do before filing bugs to search all bugs (including resolved ones) filed in the last two months, and use Myk's "find a specific bug" feature to get better relevance.

6. We currently have much more active people in the forums than Bugzilla. Try and convert more forum participants into QA triagers. Suggestions for how to do this are welcome. I think we need a good document which we can publicise. This one is OK but needs work.

7. Give more people the "canconfirm" privilege by publicising how to get it more widely. Get triagers to suggest candidates based on good bug reports they've seen. (Some have suggested giving it to everyone by default.)

8. Get some of the webtool-writing crew Blake recruited to to write tools to mine the database and suggest likely duplicates.

9. Add a READY state which goes between NEW and ASSIGNED. Bugs move to READY when they could be picked up and fixed without further work. So they are clear, have steps to reproduce, and a testcase if applicable.

10. Reorder the product list page to put Firefox and Thunderbird at the top.

11. Check the b.m.o. Referer logs to see who links to us, and get the top ones to relink directly to the support pages.

What do you think? I've numbered them this time for ease of reference :-)

Other suggestions are welcome - please give them a number too, starting after mine. Remember, we are looking for low effort, low disruption, high impact. So blue-sky Bugzilla feature suggestions probably won't fly.

Oracle DBA Wanted

The mozilla.org talkback servers are currently down. In order to resurrect them, I am told we need someone with serious Oracle DBA experience. If you are such a person, or know of someone willing to help, chofmann@mozilla.org wants to hear from you :-)

Update: We've got enough offers now, thanks :-)

Automated UNCONFIRMED resolution

This is what the "Bugzilla Data Mining" entries have been leading up to. We've decided to attempt to use a semi-automated procedure to resolve some of the older untriaged UNCONFIRMED bugs. Here's the plan - please let us know what you think.

• Once a date is chosen, we raise awareness of the following procedure using blogs, newsgroups and websites. We don't want anyone to get surprised.

• At the appointed time, we turn off Bugzilla access to all except the person doing the change. This is to prevent things changing under us.

• We search for all bugs in the Browser, Firefox, MailNews, and Thunderbird products[0] in state UNCONFIRMED where Last Changed Date is more than two months before the present.
  
  (The data mining used "bugs not confirmed after two months" - this is a subset of that. We are using "bugs not confirmed, and untouched in the last two months", because then we won't accidentally catch ones which are being worked on, but taking a long time to get confirmed.)

• We then Change Multiple Bugs, and add the following comment[1]:

  This is an automated message.

  This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after two months are highly unlikely to ever actually be fixed.

  If you can still reproduce this problem in the latest version of the product (available from http://www.mozilla.org/products/) or, for feature requests, if you still believe we should implement this feature, please visit the URL of this bug (given in this mail) and add a comment to that effect, giving more reproduction information if you have it.

  If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter.
  

• Two weeks later, we make a buglist of all bugs in the original list which have not changed since the date we added the above comment.

• Do Change Multiple Bugs, add a "robo-resolved" keyword, and resolve them as WORKSFORME[2] with the following comment:

  "This bug has been automatically resolved after a certain period of inactivity (see above comment). Anyone who thinks this is incorrect should feel free to reopen it."

So that's our best shot. Any such process will never be perfect - but, in a perfect world, we'd have the manpower to triage all the UNCONFIRMEDs properly. But we don't. So, we are looking for something which keeps as high a percentage of the good ones, and throws away as high a percentage of the bad ones as possible.

Here's the logic. Bugs which haven't been confirmed after two months are very unlikely to end up as FIXED - either they get fixed via another bug, or get fixed 'accidentally', or the code gets rewritten, or something else. We could just throw the lot away and not lose too much. But we want to do better, so we try and find the ones which might, by getting the reporters to reconfirm them. Getting reporters to reconfirm bugs is good because it tells us that they still see it and, just as importantly, they are still interested in helping us fix it.

Once this procedure is completed, we would use BugDays and other mechanisms to attack the bugs which had received comments, with the aim of resolving them or confirming them, starting with the oldest. This way, we hope to make a significant dent in the UNCO pile, and turn up the needles in our giant haystack.

[0] If you are the module owner of another product, and want to opt-in, shout.

[1] People who are not interested in reading these mails can create a filter and use Run Filters On Folder in Mozilla or Thunderbird, targetting the phrase "This is an automated message".

[2] We either resolve as WORKSFORME, or OUTOFDATE if we can get that resolution added to Bugzilla. This depends on whether anyone has time to make the modification.

Bugzilla Data Mining (2)

OK, I figured out how to do this automatically.

So, since the beginning of time, there have been 9567 bugs in the Browser, MailNews, Firefox and Thunderbird products which started as UNCONFIRMED, got confirmed before they got resolved[0], and ended up FIXED. This is a table of how long each of them took to get confirmed:

So the larger data set bears out the results from the smaller one. After 3 months, we've squeezed 96.7% of the juice out of the UNCO pile. (And, these figures don't take into account the case when someone finds a long-dead bug which doesn't occur any more and marks it FIXED instead of WORKSFORME.) Yet, we have 8200 UNCO bugs open which are older than that.

[0] This is a technical limitation. There were 11912 overall; i.e. 2345 went straight from UNCO to FIXED. I don't think leaving them out of the table skews the data, but I'll listen to arguments that say it does.

Super Size Me - The "Debate"

Browsing The Register, as one does, I couldn't help but notice an intrusive box ad (see left.)

"Wow", I thought. "McDonalds have set up a message board for people to discuss 'Super Size Me'. How open-minded of them. I'm thinking of seeing it; let's head over there and see what's going on."

Of course, that's not what it is. It's a carefully-worded, one-sided Flash-based effort. Of course, I doubt Super Size Me is a paragon of even-handedness, but still, using a site url of "supersizeme-thedebate.co.uk" for this propaganda seems a bit rich.

The funniest bit is that a entire website specifically designed to minimise the damage to their business caused by Super Size Me has a 'True or False' which says:

True or False: "That film 'Super Size Me' has really got McDonald's on the run."

Answer: False...

Get Gmail Invites Here!

Over the last two weeks, I've been surprised to find that the most popular entry on my blog has been the one about Bernd's plan for using Gmail invites to bribe people to produce layout testcases. It has 35 comments, most of which are random people asking for accounts.

It probably seems incredible to most of the readership of this blog, who can easily lay their hands on a Gmail invite if they want one, but apparently there is a mass of people out there who are desperate to get on the Gmail train.

So, listen up, all those who want a Gmail invite! We are giving 1500 of them away. So go gettem.

Bugzilla Data Mining

I've been doing some data mining on b.m.o. recently, and have got some interesting results. I've been particularly looking at UNCONFIRMED bugs (of which we have a very large number) and what happens to them.

Any bug which ends up FIXED is a great thing. Almost any other bug is a net drain on resources - we'd have been better off if it had never existed. So, in an ideal world, all filed bugs would end up FIXED (and get filed with a crystal-clear description, a reduced testcase, and a pointer into the code...).

So I looked at all bugs filed as UNCO in the week of 2004-04-22 to 2004-04-28 (6 months ago) which eventually ended up FIXED. There were 38 of them. This is a chart of how long it took them to get confirmed. It was made by hand, checking the Bug Activity of each one.

< 1 day    18
< 1 week   13
< 1 month   3
< 2 months
> 2 months

Some bugs went straight from UNCO to FIXED; they were fixed after:

< 1 day
< 1 week    2
< 1 month
< 2 months  2 (but both of these should have been WORKSFORME)
> 2 months

So, based on this sample, any bug which hasn't been confirmed after two months is very unlikely to become FIXED - no examples were found of this. (Please point out any flaws in this logic in the comments.)

So what are we going to do with this fact? More on that tomorrow.

Bugzilla "Limitations" 3: Users And Bugs Are Permanent

Another class of requests we often get is "how do I delete this user?" or "how do I delete this bug?". Jeff has left the company to go and rediscover himself in the high Himalaya, and that humorous "My shirts smell" bug you filed as #1 doesn't seem quite so funny now the system is used by 3000 people.

Nevertheless, bug or user deletion is a bad thing to do, for much the same reasons as deleting comments - it alters history. Jeff did have an account and said a load of stuff, and no-one is served by having that fact obscured. Particularly not the people who responded to it.

So have a "useless/test bugs" dumping ground. Rename departed users to "Joe Public (gone)". Change their email addresses to joe.public@hotmail.com.invalid if you like. But don't try and erase all evidence of their existence. Apart from anything else, it's not nice.

Bugzilla actually does have user-deletion and bug-deletion code, but it's unmaintained, turned off by default, and there are big warnings next to it saying "Warning!", (a good start), "This code may corrupt your database, Paypal your bank balance to the RIAA and cause you to run out of toilet paper just before guests arrive." Or something like that. We even get people who turn it on and then say "Hey! Now sanitycheck.cgi is complaining!" Well, yeah :-)

Of course, it could be argued that we are just being lazy. All of this philosophical talk about "altering history" is just an excuse not to get off our backsides and do the work. Well, it's true that this is not a major architectural assumption like sequential bug numbers. Proper bug deletion code, which maintained data integrity, could be written. But we haven't - because (and this is what this series is all about) we don't write good code to encourage bad practice. If people want to do dumb stuff, they can write the code for it on their own time ;-)

All Your Programs Are Belong To Us

Does this article scare anyone else?

With this in mind, ASU [Arizona State University] gives every student an ACE software image that includes Windows, an application stack, a productivity suite and any other files needed for a particular quarter. ASU cuts off access to the USB and floppy drives for this software image and basically blocks the students from changing the container's configuration. After a given quarter is over, the image - or container - expires and is deleted from the laptop.

Bring a new meaning to the term 'vapourware'...

Colour-Coded Connector Confusion

Ever wondered why all of your PC's connectors are weird colours, and who gets to decide what colour is what?

Intrigued by the fact that my old Gateway keyboard (on which I wore out the spacebar after less than a year of use) had an orange connector and my new Dell one had a purple one, and that my microphone connector was a rather effeminate shade of pink, I went in search of the answer. It turns out that the colours are defined by the PC99 standard (careful, it's 1.5MB of PDF). The standard uses Pantone rather than RGB, so I've converted them to a swatch for you.

So now you know. (Bad Gateway! No cookie!) How does your computer score? Start with 10 points, and subtract one for each incorrectly-coloured connector or plug.

Strip Club Source Code

From Reuters via Slashdot: Microsoft are making the Office source code available to world governments so they can audit it for security flaws. This follows on from a program to make Windows available in a similar way.

Of course, this is "strip club source code"[0] - look, but don't touch. Are these governments allowed to make fixes, compile the code and use and redistribute the resulting binaries? No? Well then...

Microsoft: Here. Use these binaries. They are made from the source code you audited.

Government: How do we know that?

Microsoft: Er... because we say so, and we're nice people?

Diebold: And if you believe that, we have some voting machines to sell you...

You need the freedoms free software gives you to guarantee the integrity of your IT infrastructure. With any other form of "access to source code", you are just doing free QA for the company concerned.

[0] I've never visited a strip club, and never would, but I still think it's a catchy name.

BIFF

I was looking at BIFF programs, and came across this wonderful demonstration of the fact that geeks understand the word "useful" in a completely different way to the rest of the world.

tkbiff is yet another program to alert you to incoming mail. tkbiff allows arbitrary commands to be executed upon mail reception. If you like programs like xbiff++ but wish they were more flexible, then you'll like tkbiff. For example, suppose you want to play your favorite song when you get mail that mentions "windsurfing" but play a groan when you get mail from your manager unless you're mentioned in the cc in which case don't play anything. This kind of thing is easy to do with tkbiff.

Someone has Too Much Time.

Huge Loan's Available for Mozilla Startups

[No, that's not a misplaced apostrophe. Read on.]

Anyone doing a Mozilla startup? From netscape.public.mozilla.browser:

Hi:

Please pass along my contact information to any members that may be looking to secure initial Tier 1 angel or venture funding around Mozilla initiatives. Particularly interested in XSLT, LDAP, RDF, and security/embed focus.

Hugh J. Sloan III
Managing Director & Founder
Sand Hill EC

http://groups.yahoo.com/group/SandHillEC/
http://www.ryze.com/go/SandHillEC

At first I thought this had to be a joke. I mean, it's perfectly possible that someone would want to put money into Mozilla startups. No problems there. Eminently sensible.But what real venture capital group has a founder called "Huge Loan"?

However, following the links, it really does seem to be genuine...

Firewall Stupidity

A company or ISP is worried about crackers. So it installs a firewall which blocks all ports except the ones for services it wants people to use, such as 80 (HTTP) and 443 (HTTPS). It then institutes a complicated policy and procedure for getting new ports opened, complete with risk assessments.

What's wrong with this picture? Isn't this just good security practice?

Well, users don't want to just use HTTP, and application developers want people to be able to download and install their applications. So along comes HTTP tunnelling. Everything gets wrapped in HTTP and a bunch of hacks to make connections appear persistent, and passes over port 80 - or encased in SSL and passed over port 443, where firewalls can't see what's going on.

Of course, HTTP is a stateless, transaction-oriented protocol, and not designed for this sort of use. As some outrageous hacks have proved, you can tunnel practically anything over anything else, but the performance always degrades.

So, the entire point of ports is circumvented, and we end up with applications which perform worse on the client and take more resources on the server, and security which is no better. Everyone loses - network admins, users and application developers.

So what's the conclusion? Default-deny firewall configurations are not actually more secure, because their end effect is to cause users and applications to bypass the system. And, particularly with tunnelling via SSL, there's nothing an admin can do about it, assuming they want HTTPS to keep working.

Amusing Spam

A couple of gems which have crossed my inbox and caught my eye this week:

Title: FW: Ministry TRAINING
To: gerv@gerv.net

You can become a legally ordained minister within 48 hours

As a minister, you will be authorized to perform the rites and ceremonies of the church!

Perform Weddings, Funerals, Perform Baptisms, Forgiveness of Sins
Visit Correctional Facilities

Want to start your own church?

Press here to find out how

Three things struck me.

• The title is "Ministry Training", but then you can become a minister in 48 hours. Some might argue that slightly more qualifications are required than that.
  
• It implies that the job of a minister is to perform rites and ceremonies. I suggest the emphasis is better placed elsewhere.
  
• And of course, there's the amusing assertion that this "course" somehow makes you qualified to Perform the Forgiveness of Sins. But who can forgive sins but God alone?
  

The second piece of semi-spam was actually a webmail footer. I'm sure you've all seen the ones for MSN or Yahoo personals which basically say "click here to get a date". In India, they do things somewhat differently:

Yahoo! India Matrimony: Find your life partner online.

Firefox Takes Off

(No, I don't mean Clint).

www.mozilla.org has had twice as many hits per day this month as last month. We're currently serving 45 million items a day, or about 520 items a second. And update.mozilla.org seems to be pumping it out as well...

And we haven't even reached 1.0 yet...

Dell Tech Support Scripts

Hixie writes (about half way down) about "reverse-engineering the Dell Support Broken Disk Script" in order to persuade Dell to fix his Inspiron.

This week, due to lack of 31337 script reverse-engineering skills, I had to execute the entirety of the Dell Support Broken CD-Writer Script with a nice lady from Bangalore. The writer had died part way through a batch of CDs, and was refusing to recognise that I'd inserted a blank disk. Several bits of the conversation went like this:

"But it can't be a software problem, because it won't write CDs under Linux either."

"Of course, sir. Now, if you'll just roll back your Windows install for me..."

Dell technical support people have an amazing way of agreeing with everything you say and then politely ignoring it. Executing the script took the best part of an hour, and would probably have taken much longer if I didn't know what I was doing and so was able to do it very quickly when asked.

It's almost not worth it for a £30 component. Hey, wait, maybe that's their plan...

Bugzilla "Limitations" 2: Comments Are Permanent

Another "limitation" of Bugzilla is that you can't edit comments after you've submitted them. Someone who wants this ability usually puts forward one or more of the following arguments:

• What if the comment turns out to be factually wrong?
• What if I change my mind about something?
• What about confidential info accidentally added?
• What if I make a typo?

Editing comments is a bad idea because it is altering history. You said that stuff and, even if you wish you hadn't, it had an effect on things other people had said. If you revise what you said, and they don't, then there's potential for confusion and inconsistency.

I sometimes use another bug tracking system whose comments are basically big textboxes. If you have something to say, you just add it at the bottom and hit Save - but you can also edit, remove or rearrange anything anyone else has said before. (Admittedly, this is an extreme case of comment editing.)

This system has several undesirable effects. The rationale for decisions often gets lost by people "tidying up". You can't be certain that you are reading what someone else read before they said what they said.

But what about those initial reasons for permitting it?

• What if the comment turns out to be factually wrong? - Then add another one and correct it
• What if I change my mind about something? - Then add another comment with your new view, explaining why you changed your mind
• What about confidential info accidentally added? - That's what the "insiders" function is for
• What if I make a typo? - Type more carefully; everyone knows what you meant anyway

Comment editing, along with any form of history alteration, isn't necessary and actually decreases the reliability and usability of your bug tracking system. Don't go there.

X-Lite Softphone UI Rant

The folly of designing computer programs to look like real-world objects is well documented. However, having just come across X-Lite, a SIP Softphone, I feel a rant coming on.

However, I'm not going to focus on their main UI (image link), because the flaws in that are obvious for all to see. Instead, the image to the right is a screenshot of their configuration dialog, which is the first thing you are presented with when starting the app. In fact, this static PNG gives you a good idea of the user experience as well as the look, because their custom controls don't react in any way to being moused over.

See that widget on the left (note: not the right, where everyone else puts it)? It's not really a scroll bar. The vertical line is just decoration. Clicking it or those two little black arrows does nothing. The larger arrows don't scroll the viewport, they move the selection, and the viewport only scrolls when the selection reaches the top or bottom. The SELECT button appears to do nothing at all.

The ? in the title bar, which usually indicates local or context-sensitive help, actually hijacks your web browser and brings up an X-Lite web page. Er, excuse me, I was using that browser window?

The little icon in the top left of the "title bar", which produces a menu on normal windows, does absolutely nothing. Double-clicking it doesn't close the window. The only window resize point is in the bottom right corner, although there are no visible clues to tell you this. Perhaps we should be grateful that they've provided one at all.

Trying to edit your settings is equally miserable. For boolean items, instead of checkboxes, it takes you to an entirely new screen where you have to select either Yes or No from a two item list, press Enter to move the tick, and then click Back. This turns a one-click operation into a four-click, two-screen one. There's no way of cancelling a settings change once you've made it; if you click BACK, your settings are saved anyway. Even closing the window using the X saves the settings.

But the most amusing thing is that their website puts in the feature list:

Intuitive user interface & Menu. Easy to navigate and configure.

Bugzilla "Limitations" 1: Bug Numbers Are Unique

One "limitation" of Bugzilla is that bug numbers are unique in a particular installation. To most people, this may more like common sense than a restriction - but we regularly get questions in the newsgroup like this one:

If I have two products... and I add a new bug to Product1, the bug number is 1. If I then add a new bug to Product2, the bug number is sequential (ie. 2). In this example there would be no bug number '2' for Product1. Ideally we would want Product1 to have bug numbering sequentially specific to the product, so if there are 100 bugs for Product1 then the bugs are numbered from 1 to 100.

Usually, the questioner doesn't explain why it is that they want to do this (although often it's not them, but their management driving the request). If pressed, they sometimes say something about "easier to manage or understand" and "having no holes in the bug numbering space". However, the root reason is almost always a serious misunderstanding about how software development in general, and bug tracking in particular, works.

If someone cares what absolute value a bug number has, or how many bugs there are in the system (either in total or for a particular product), then they must be attributing some meaning to those numbers. 95% of the time, their view is that the smaller the number of bugs, or the smaller the change in that number in a week, the less buggy the product. They often don't realise that this is what they think, but they do.

Of course, a moment's thought will reveal that this view is nonsense. The mozilla.org Bugzilla has over 250,000 bugs (it passed that milestone recently), including 47,000 open ones. The bug counts have increased steadily since the very beginning of the project. Does this fact by itself mean that Mozilla has been getting buggier and buggier since 1998? No, of course not.

It would therefore be tempting to dismiss such thinking as harmless foolishness. However, this attitude, and the culture that stems from it, can be far more damaging to good software development than one might think. If having fewer bugs is encouraged, then:

• people avoid the bug system and track bugs in spreadsheets, on post-it notes and on the back of their hand
• people check in lots of code under a single bug number, making it hard to see what changes went together
• problems fall through the cracks and don't get reported at all.

Over and above all that, the person doesn't normally explain what's supposed to happen the first time a bug gets moved from one product to another, perhaps because it was originally misfiled. Do you change the number? Or have two the same number in a particular product?

The highest bug number in a bug system are a measure of only one thing - the number of times someone has pressed "Submit" on the entry form since you set the system up. Nothing else.

[Further reading (and my inspiration): Jouni Heikniemi]

Joel's Second Book

Joel says his second book is about to go into another printing. It's original US title appears to have been refactored for the UK market. :-)

Bugzilla "Limitations" 0: Introduction

I'm planning to write an occasional series of postings on "limitations" of Bugzilla which are actually features. As Joel has suggested (more than once; see three paragraphs from the bottom), sometimes you purposefully avoid adding a feature to a product in order to make it more usable.

This has been generally inspired by frequently asked questions in netscape.public.mozilla.webtools, and specifically by Jouni Heikniemi's recent post. He talked about bug numbers being unique across an installation, which will be the topic I'll address first, but I have at least four more ideas in the pipeline.

Look out for the first in the series tomorrow.

Fish Update

Steve Parkinson has posted a couple of static images of the Netscape fish tank as it is now, at the back of a conference room in building 12 on the new, smaller Netscape/AOL campus. Sadly, it's no longer wired for pictures.

The fish, they say "NO" to internet webcam paparazzi. :-)

"Will Work For Gmail Invite"

Bernd Mielke has come up with an innovative way of getting help in layout; in the style of the BugAThon, he's giving away Gmail invites to people who write reduced testcases. It'll be interesting to see whether he gets any takers...

Calmness In The Face Of A Hurricane

If I lived in Florida, I certainly wouldn't have hung around to set one of these up...

Subject: Out of Office AutoReply: Add Motorola to Bugzilla list
Date: Mon, 6 Sep 2004 11:56:13 -0400
From: Levy Rami-ERL005 <Rami.Levy (at) motorola.com>
To: Gervase Markham <gerv (at) mozilla.org>

I will be out of the office from Sept 2-3, 2004. I will return on Monday, Sept.6, 2004 (depending on the hurricane). I will have no access to email during this time. For urgent matters please leave me a voicemail or send an SMS and I will answer your message as soon as I can.
Thank you.
Rami

Update: Email addresses obfuscated.

Trademark Policy for Localisations v.1

After a long wait and a shedload of work from Bart, the Mozilla Europe crew, the MLP crew and myself, v.1 of the Localisation Trademark Policy is available. Thanks to everyone who gave feedback.

Watch this space for further, more general policy documents in this area.

Camino Marketing (2)

rebron has written a page comparing the different mozilla.org products, to help users choose between them. In many ways, it confirms the problem I see with marketing Camino. I've interspersed the content with the thoughts of a hypothetical user.

Camino™ is a web browser optimized for Mac OS X with a Cocoa user interface, and powerful Gecko layout engine.

So what on earth's a Cocoa user interface? Does this mean the theme is brown? And aren't all mozilla.org products built on Gecko, as the boxout at the top of the page says?

Mac OS X users looking for an alternative to Firefox or Apple's Safari should consider using Camino.

But why would I want an alternative to Firefox anyway? Does it suck? Or is Camino only for people who have downloaded Firefox and decided they don't like it?

Key features in Camino include:

• Native Cocoa user interface for seamless integration with Mac OS X
• Bookmark manager integration with Rendezvous and Address Book
• Remembers website passwords with your Keychain

But doesn't Firefox remember passwords too?

• Tabbed browsing and Pop-up blocker
• Google Search Bar

Firefox has all of these.

So, those who argue the MoFo should promote both, what should this page actually say to explain the differences?

[To be clear: this blog post is not intended to knock Camino. Not being a Mac user, I've never tried it, but I hear and do not doubt that it's an excellent bit of software.]

Camino Marketing

Zach Lipton has commented that the new mozilla.org website redesign has knocked Camino off the front page (along with Bugzilla, incidentally).

I think this is symptomatic of a larger problem - as Firefox on Mac OS X matures, and as Firefox as a whole goes to 1.0 and we try and ride the wave of free publicity and gain market share, how does the Mozilla Foundation present the available options to OS X users?

We seem to have what I believe marketers call a "channel conflict" - two products in the same space. This is much worse than the Suite-vs.-Firefox problem; you can differentiate those with "The suite is for users who want a Netscape 4.x replacement; Firefox is for those who want an IE replacement."

But, in this case, Firefox is a modern, slim, fast, stand-alone browser that does one thing well on all platforms. Camino is a modern, slim, fast, stand-alone browser that does one thing well on the Mac. I'm not at all sure we can start explaining to users what native widgets are and why they might or might not want them - so how can this dilemma be resolved?

More Disruptive Innovations

I need to go on holiday more often, if people come up with smart ideas like HTML overlays while I am away. Kudos to Dan Glazman and Laurent Jouanneau of Disruptive Innovations (obviously a wise hiring, Dan :-).

My first thought is: if and when we get browsers with native overlay support, how do you prevent the backwards-compatibility JavaScript executing and thereby including two copies of the overlay contents? You'd need to mark the script in some way to indicate that it was the special overlaying script, so the UA could ignore it. I see four options, all horrible:

1. Require that the script have a specific name, e.g."HTMLoverlays.js"
2. Specify a correct "type" attribute and then abuse the deprecated "language" attribute (assuming this works in common browsers), e.g. language="HTMLOverlays".
3. Put a magic value inside the <script> tag, e.g. <script src="..." ...>HTMLOverlay</script>. This content should be ignored by compliant UAs if the <script> has a src attribute.
4. Use a <link> tag with a special "rel" to provide an alternate link to the script; the UA matches up the two filenames and ignores the script.

Any more ideas for solving this problem?

MNG revisited

(I'm back, and I've reopened comments. Discuss away.)

Mike Connor has taken me to task about perceived inaccuracies in my MNG post.

He misrepresents my first point, which was dealing with perceived bloat in the spec and features, not the implementation. I believe my point still stands - I've heard mozilla.org people argue that the SVG spec is terribly overdone, but that's not being used as an argument against implementing it.

The basis of my post, including all the figures except one, was information from a libpng hacker, who stated that there were no outstanding issues with replacing libpng with libmng and still getting the necessary PNG performance. So I stand by my 48k figure, and my assertion that there are no issues with replacing libpng with libmng.

He also says:

Its also a little shocking that Gerv missed the point of apng, which is to provide a format that can be animated, but still degrades gracefully on other browsers.

I was originally told that the point of apng was to allow Mozilla chrome to move away from animated GIFs. If it's now a new image format for the web, that's a rather different question, and perhaps not something we should be designing on the back of an envelope in ten minutes.

I had a better discussion with Brendan via email and IRC, but I don't currently have his permission to post it.

In any event, it seems that the APNG folks and the PNG folks are chatting away fairly happily. If something like APNG becomes a revision of the PNG spec, I quite agree that it would be the best result all round. In that case, I'd like to agree with calls to revert to the 0.2 spec behaviour of putting the additional image data after the IEND chunk rather than nesting chunks, if that becomes technically and politically possible. As Adam Costello says, it's less in line with the wording of the current spec, but more in line with its spirit.

Also, it seems to make sense to me for the default image (the first in the stream) to be the last in the animation. This is more likely IMO to produce a better degredation in the common case. Would it be too complicated for an APNG-aware decoder to "put the first image to the back"? Could one do it simply by shuffling the objects representing the chunks in memory?