« Sieve (and other things) in XML | Main | Interesting study about instant messaging and interruptions... »
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:
- Gecko (notable changes include performance, native widgets, and memory footprint)
- Toolkit (especially useful to Thunderbird users is the add-on manager overhaul)
- MailNews/Tb (a large melange of bugfixes, feature work, and lots of code cleanup that makes life easier on extension authors)
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:
- the strategic value in maintaining alignment with the rest of the Mozilla project
- anticipated performance and feature improvements in the 1.9.1 cycle
- the continuously improving stability of the trunk, thanks in large part to automated testing policies
- the relatively conservative roadmap for 1.9.1 discussed in mozilla.dev.planning
- the timing of 1.9.1 (estimates current at the time of this writing indicate 4Q/08 or 1Q/09)
- the non-trivial complications of handling maintenance releases from a branch other than the one getting primary focus from Gecko and Firefox developers
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:
- Discuss the above proposal.
- Add owner annotations to all the items on the Thunderbird 3 page which have owners, and mark the rest as unowned.
- Talk to the owners of those items about what they think the above roadmap would mean for them.
- Nail down which things seem to make more sense for Thunderbird v.next and document that.
- Advertise for folks to step up to the plate to own stuff that they are motivated to see happen sooner (or are as-yet unowned).
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 June 26, 2008 7:40 PM
Trackback Pings
TrackBack URL for this entry:
http://weblogs.mozillazine.org/mt/track.cgi/12698
Comments
I think you are right about the Addons work. In fact, it might make sense for the team to consider the in-product UI to be the primary access method for Addons in Thunderbird.
This might involve, for example, putting a big message on addons.mozilla.org/en-US/thunderbird/ saying "You can also browse and easily install Thunderbird addons through Tools | Add-ons", and perhaps having that window open larger by default.
I also think Simple Autoconfig is a killer improvement, even if we just end up using the existing "ship the data" mechanisms rather than something smarter. Repositories of account setup info already exist (e.g. Nokia has one for their tablets) which we might request access to. Or we could start a project to give everyone access to the data. (CC-BY-SA or similar to make sure the commons always grew.)
Gerv
Posted by: Gerv at June 27, 2008 1:27 AM
Why not just base a TB3 on Gecko 1.9 and stabilise for a quick release dropping all unfinished features? Thunderbird 3.1 can have more user visible changes and "demorkification" and 3.5 can go the whole hog.
Don't the platform improvements in 1.9, particularly when it comes to performance, security and memory consumption, justify a release ASAP?
Posted by: Farhad at June 27, 2008 3:08 AM
planet.mozilla.org seems to strip out all your paragraphs?
Posted by: Philip Chee at June 27, 2008 5:17 AM
Hey Dan,
It's great to have a discussion around this. Sorry for not bringing much to the table other than "ship it soon"! I understand that it's tempting to use 1.9.1, considering that it has a low risk of being significantly delayed. What you have written sounds like a pretty good plan!
--Tristan
Posted by: Tristan at June 27, 2008 7:57 AM
I think it's important to release early and often and Tb3 should be based on Gecko 1.9.1, but a minimum of features visible for end users is essential to justify switching to the newest release (for example a pre-installed lightning extension, a overhauled address book, tabbed interface, or Simple Autoconfig mentioned by Gerv). So, don't rush, finish some important enhancements/features and then release in Q1/2009 on top of Gecko 1.9.1.
Posted by: Thomas at June 29, 2008 6:49 AM
@Gerv: agreed about both Add-ons and Simple Autoconfig. Can I talk you into filing a bug about the Add-ons suggestion? (We're already tracking autoconfig work).
@Philip: yeah, yuck. I need to look into that.
@Farhad/@Thomas: I tend to agree with Thomas that we need to give end-users a reason to upgrade, and it would also be good to give them hints of how the front-end is going to evolve, which I don't think we have much of yet.
Posted by: Dan Mosedale at June 30, 2008 10:47 AM
I just thought that if half the user-facing features promised are cut, does it make sense, then to still call it Thunderbird 3.0? Would it not be be better instead to call it Thunderbird 2.5 or Thunderbird 2.8, maybe?
That would not lead to the expectations that customers usually have when new n-point-oh software (until now, Mozilla, unlike other open-source projects, played the n-point-oh releases game well) is released, but still show that Thunderbird is alive and heavily being worked on.
Posted by: Aaron Strontsman at July 1, 2008 8:05 AM
Looks good, I think it would be very scary (and foolish) to stay with 1.9. It's a bit scary already that core 1.9.1 changes aren't getting nightly thunderbird testing.
Posted by: Magnus at July 2, 2008 1:48 PM
@Aaron: that is worth thinking about. I don't think most users are likely to be conscious of our preliminary planning process, though, so I'm wouldn't want to weight that very strongly. I think the real determinant needs to be how we feel about it as we get closer to release. My hope/suspicion is that we'll have enough user-facing changes that we'll feel good about calling it 3.0.
Posted by: Dan Mosedale at July 2, 2008 4:15 PM
I think this is exactly the right plan for all the reasons you cite.
Posted by: Myk Melez at July 3, 2008 2:44 PM
Are there plans for much in the way of enhancements to the Address book/contact manager features in Thunderbird? Field additions? Home, Work and "Other" address like Outlook?
Grouping/categories and management features?
I am sure the Address book is at at the bottom of the list, but it is another component that would help with competing with Outlook vs Thunderbird type questions.
thanks
Alan
Posted by: Alan at July 5, 2008 2:56 PM