« May 2008 | Main | July 2008 »

June 26, 2008

Proposal to ship Thunderbird 3

This is a proposal for shipping Thunderbird 3. It's based on my current thinking and may well undergo substantial change before things are nailed down. I expect such change to be heavily informed by feedback on this proposal.

Development Process: Increasing Agility

In recent years, Mozilla in general (but most especially Firefox) has moved towards a more agile development process.

Milestones have become shorter and more frequent in order to alleviate the pain felt when a feature misses a specific milestone, but also to apply pressure that keeps the code from drifting away from a shippable state. To the extent that it was done; this worked fairly well in the Firefox 3 cycle and is something that we should strive for in ongoing Thunderbird work. Specifically, 8 week cycles feel like a good starting point (though we've done slightly longer cycles for 3.0a1 and 3.0a2). Generally speaking, I think we also win by shipping to end users (i.e. non-alpha and non-beta milestones) relatively frequently (yearly? or even somewhat more frequently than that?) as well for exactly the same reasons.

Quite a bit more automated testing (of both regression and unit varieties) was integrated into the development process during the Gecko 1.9 and Firefox 3 cycle to great effect. The Firefox 3 nightly builds were usable as dogfood for almost the entire year before Firefox 3 shipped, which is an order of magnitude better than Firefox 2 nightlies were, and I believe this was a direct result of all the added tests. We should very much attempt to move Thunderbird in a similar direction.

Thunderbird 3

Since We Last Shipped...

The last major Thunderbird update (version 2) was released in April 2007, from the 1.8 branch. Since that time, the trunk has progressed substantially in many areas:

Timing

An important factor that's gone into my thinking on this roadmap is that the longer we delay shipping to end-users, the longer it is until they get all of the above-mentioned goodness into their hands. Taking all of the above stuff into account, the thing that makes the most sense to me is to target a release candidate for the beginning of 2009.

What Platform?

Because of a combination of:

my belief is that the right choice is to ship Thunderbird 3 on top of Gecko 1.9.1. This entrains switching to Mercurial, which will cost us some amount of time and effort, but will hopefully also pay off in the ability to do less painful distributed development than is possible with CVS.

Dates

Working backwards assuming 8-week milestones (with a slightly longer 10-week milestone around the holiday season), we end up with something like this: 


 3.0a1         3.0a2         
===+==============+======== (Gecko 1.9)
2008-05-13  2008-07-15    ||
                          ||
                          ||    3.0b1         3.0b2         3.0rc1
             (Gecko 1.9.1) ======+==============+==============+===
                            2008-09-09    2008-11-04    2009-01-13
I expect the astute developer reading this to likely think, "Hey! That's not very many milestones! And code-freeze for the last alpha is almost here!"

Tradeoffs

The larger set of things described in the initial vision for Thunderbird 3 are all still very worthwhile, but given current resources, it seems unlikely that we'll be able to fit that amount of work into such a small number of milestones.

I believe that the importance of getting good work into the hands of end users on a regular basis trumps almost everything else. This is both for its intrinsic time-value in the hands of the user, but also because it helps maintain the real health of a software project. As a result, splitting a large set of changes into multiple releases makes much more sense than hoarding up a huge stack of changes for a long time just so that they can all be shipped at once after a lot of waiting.

Moving Forward

So the next short-order list of things to do, I think, is to:

Some Q & A

We're almost done with alphas. How can we possibly get "enough" feature work done?

In the Mozilla world, the main difference between alphas and betas has to do with risk and quality. Features typically get added and changed well into betas, though highly risky features are usually declined in this phase. This means that we will still have the opportunity to do more user-visible work.

That said, it is conceivable that this release will end up being "light" on user-visible changes. My belief is that value of simply shipping is so high (as per the reasoning earlier in this proposal) that that's worth living with. As a project, we're very much in a scaling-up mode at the moment, and in future releases, after more of that scaling up has happened, it will be easier to do larger volumes of directly user-visible work.

Given that this requires migration to Mercurial, what about tinderbox, buildbot, bonsai, etc.?

There's definite work entrained here, as there is across the entire Mozilla project. We'll do our best to minimize the pain, but there will be some. We'll benefit from the fact that Mozilla 2, and now 1.9.1 & Firefox are ahead of us here, and have blazed a trail through many of the hardest issues already.

What should our Mercurial repository strategy look like?

The current tentative plan discussed today suggests a Mercurial repository shared between Calendar, SeaMonkey, and Thunderbird. We hope to have more details nailed down shortly.

What about Lightning?

We're still very much committed to shipping Lighting as part of an upcoming release of Thunderbird. We'll be working closely with Top Lightning Hackers to try and figure out at what point in time it makes the most sense to have that happen (as we will be with all the other stuff that we had hoped to see in Tb3). In the ideal case, it will still make Thunderbird 3, but we wouldn't necessarily block Thunderbird 3 on that.

We will also certainly be working closely with the Lightning team to try and figure out the least disruptive version control migration given the ongoing work on Lightning 0.9 on the 1.8.1 branch.

What if 1.9.1 slips?

Given the profile of the changes planned for 1.9.1, the risk of it slipping a large amount of time seems small. Smaller slippages give us the opportunity to fit in more features & fixes.

What if 1.9.1 is early?

If we focus on getting necessary platform fixes and features on the radar now and into the tree soon, this shouldn't hurt us much at all. We're pretty much guaranteed to be in a better place than if we stuck with 1.9, which is already in a very risk-averse mode.

Your Feedback Appreciated...

Posted by dmose at 7:40 PM | Comments (11) | TrackBack

June 23, 2008

Sieve (and other things) in XML

A mailing list I'm on today saw a message containing a link to an internet-draft defining an XML representation of Sieve. There seems to be various of examples of this with (e.g.) iCalendar, vCard, etc. I'm always a little ambivalent about these things, because it seems like a lot of work for relatively little gain. Still, it's pretty clear that some set of people are going to use an XML representation, so it does seem better that there's a single agreed-upon representation.

Looking over that draft also led me to RFC 3470, which has interesting thoughts about XML dialect design and use.

Posted by dmose at 9:43 AM | Comments (2)