I'd like to get the ball rolling on Thunderbird 3.0alpha1.

Historically, Thunderbird & mail/news development has been managed in a
way that nightly builds on the trunk have been stable, usable, and
trustworthy with data.  I believe this is a tremendously valuable for
two reasons:

1) it makes testers willing to use nightlies for their real live data,
which is a big QA win.

2) it has the agile development property that it's easy to ship
frequently and at relatively arbitrary times.  This is particularly
useful given how hard it is to predict the timing of any given feature.

I propose that it's very worthwhile to maintain these
stability/usability invariants as much as we reasonably can going forward.

I also believe that it's really worthwhile to get a release underway.
Testers have only had nightlies for quite a while now, and the trunk is
already notably better than Tb2 in a number of ways.  Getting something
that we're willing to recommend to a wider group of people is a great
way to demonstrate real progress.

All that said, I propose the following:

We (arbitrarily) set a tentative code-freeze date for Thunderbird 3.0a1
of Tuesday, April 8, 23:59 Pacific Time.

We create a blocking-thunderbird3.0a1 flag to indicate stuff that we
really can't ship without (e.g. serious usability problems, bad dataloss
or regressions).  It seems unlikely that there would be very many of
these bugs.

We create a wanted-thunderbird3.0a1 flag that would be used mostly as a
way to help people who are looking to hack find bugs that are
high-impact and better done sooner rather than later.

Notably missing from this plan is a ton of discussion about how this all
relates to Thunderbird 3 as a whole.  There's still some work to happen
there, and it feels to me as though it's important to get a release
rolling without blocking on that.

Thoughts?

Dan

That would be almost 2 years and 8 months of code changes on trunk since
Gecko 1.8 branched on 12 Aug 05.

For triagers, nominating is straight-forward, and the plus-ed ones get
attention as well. It'll be important to note what happens to the bugs
that become minus-ed from these flags, some of which may not be
important for an alpha release but might be for later releases.

How would they remain on the radar? (probably get nominated
blocking/wanted-thunderbird3.0a2 once that comes around? or something else?)

Next, will anything be done to the existing blocking-thunderbird3 flag?
Will it be replaced by the new flags? (Bug 306324 is blocking that,
while another 79 are nominated as of time of writing)

Gary

It also gives a solid target for extension authors. I am reluctant to
test trunk Thunderbird because there are a couple of extensions I rely
on whose authors have said "I can't support trunk; it moves too much".
Doing a "relatively stable" alpha release allows them a fixed target,
enabling long-term testing by people who don't want to track trunk that
closely.

Missed you at FOSDEM, by the way. Hope you are feeling better.

Gerv

How much stability are we looking for? I ask because we're in the middle
of some significant address book interface refactoring and it'd be
really nice to get that done for TB 3.

There's also the password manager migration, which could also be
significant for some extensions.

Standard8

Agreed.  We're not nearly far enough along to start promising stable APIs.

Dan

They probably want to be nominated for blocking-thunderbird3 at the same
time.

I don't see why we couldn't use that in place (and probably add a
wanted-thunderbird3 flag as well).

Dan

On Feb 27, 1:22 pm, Dan Mosedale <dm...@mozilla.org> wrote:

Personally - I would like to see the component getting closer to
compiling with XULRunner. I tried it last week and there are a few
interfaces in addressbook (nsIAutoCompleteSession?) that aren't
included by default in XULRunner. With moving across country, I
haven't been keeping up on the latest happenings - so I'm not sure if
Standard8's changes are running along those lines.

I'll definitely attempt to invest some time in helping move towards
that goal.

- Nick Kreeger

I'm with you (if we're going to ship something - ever - we have to start
doing alphas, and giving people the feeling that they don't have forever
to write the code of their dreams), assuming that MoMess has a build
engineer who's about to start, and will be up to speed enough that he
can do a release with very little help by then.

Otherwise, you're right back to one of the primary reasons MoMess
exists: MoCo's build engineers *will* work on Fx 3 before they work on
Tb 3.0a1; they *will* work on Fx 2.0.0.1x before they work on Tb 3.0a1;
if you're counting on them to do the release, you need to schedule it
for "a few weeks after the Fx 2.x release after the release of Fx 3,
barring an early Fx 3.0.1" or roughly "pretty sure sometime before
August, or September for sure, and maybe earlier, or not."

In general, yes, but... shipping a1 really needs to be the start of a
plan that includes a2, and a3, and so on. Having a single blessed
nightly called an alpha, that we know is full of broken shards, but
won't actually eat your mail or refuse to send mail (once you persuade
it with the proper and more strict STARTTLS and auth settings), doesn't
help if we have no real intention of getting the people we persuade to
try it off that, and on to the next one, in some reasonably short time.

The Fx six week plan always felt a little rushed, but then if you do
eight week alphas, you're stranding people who won't use nightlies with
two month old trunk code, which is ancient. So really, saying we're
going to do an alpha in six weeks should probably mean that from here on
out, we aren't going to land anything that we can't get into
doesn't-kill-kittens shape in six weeks. That's easy for me, but then
nobody's expecting me to rewrite mime.

Funny you should mention that; it's the reason my addon author quoted
for not updating his addon :-)

Gerv

AFAIK the libmime rewrite is not currently required for Tb3, let alone
Tb3a1.

In general, I'd be wary of tackling that kind of low-level rewrite until
we have better test coverage in particular, given the lack of ownership
of that code from what I hear.

--da

Dan Mosedale aber hob zu reden an und schrieb:

Having an Alpha release(!) just in the middle of nowhere isn't
particular helpful for extension authors as such, the Alpha should have
a decent connection to a final release. Details may change, but the
greater goal should be visible or at least tagged as "don't rely on
$feature to work, we're currently changing that" (eg easy Mork
replacements or something like that).

"Thunderbird 3.0a1" gives the impression of more Alphas to come - on a
regular basis? Monthly? Hexweekly? Based in "contentual" requirements?

Karsten
--
Feel free to correct my English. :)

I think "in the middle of nowhere" is a mischaracterization.  The idea
is that it's helpful to the project to get back to a world where we're
releasing software relatively regularly.  Among other things, it has the
following positive properties:

1) stabilizes the trunk in a way to make it clear that we think a larger
number of people should be comfortable using this than just random nightlies
2) sends a message that we're marching down a path that leads to
Thunderbird 3, not just spinning our wheels

While neither of these things are directly helpful to extension authors,
I'll assert that they're both indirectly helpful.  In particular, item 1
gives them something to target.

It seems to me that you're underestimating the value of regular
releases.  The two points I made above are enough to count as a "decent
connection," I'd say.

I've been working under the assumption that calling something an alpha
makes it pretty clear that a fair amount of churn is still expected.
Clearly, we'll need to document the specifics of that churn in the
release notes, if nothing else.  Do you think that's insufficient?

Indeed, we still need to sort this out.  My belief is that it's worth
putting a stake in the ground to ship _something_ before it's all sorted
out.  Having that stake gives people something to focus on while the
sorting out happens.

A large part of this is that the trunk feels like a better app just by
virtue of all the work that has already landed since the Thunderbird 2
timeframe (both in mail & mailnews as well as the switch to trunk Gecko).

Dan

Yeah, moving towards a XULRunner (or at least libxul) world is a fine thing.

At one point, I was under the impression that bsmedberg was specifically
grandfathering the xpfe autocomplete stuff into XULRunner in order to
make it easier on.  Did that not end up happening?

(Though moving towards a pure toolkit world still seems like the right
long-term plan in order to take advantage of the larger number of people
who are likely interested in maintaining that code).

Great!

Dan

Easier on Thunderbird, that is.

Dan

A very good point.  I can't report anything on this right at the moment,
but hopefully there will be more news on this front soon.

Absolutely.  The idea is that getting this started buys a little bit of
time to continue sorting out bigger picture questions.

That's an interesting point.  I would tend to agree that ~6 week cycles
feel rushed.  So I'm somewhat inclined to think that we should go with
an ~8 week cycle time instead.  Of course, my initial 6 week (now 5!)
proposal was just until code-freeze, so chances are that it meant more
like 7 or 8 weeks until actual ship anyway.

In fact, a big part of my motivation for starting this thread was to get
the approximate time frame on developers' radar, and given them a chance
to say whether or not they think it makes sense with specific regard to
whatever it is they happen to be hacking on right now.  So I'm
definitely interested in hearing what a 6 or 8 week time frame might
mean for (e.g.) STEEL, addrbook de-Morkification, etc.

Dan