[Fwd: Re: Scheduling a trunk alpha]
Boris Zbarsky
-------- Original Message --------
From: Darin Fisher <dar...@gmail.com>
Newsgroups: mozilla.dev.platform
On 4/11/06, Boris Zbarsky <bzba...@mit.edu> wrote:
> Now that we've convinced people that FF 3 alpha is not out yet, let's figure out
> when we _do_ plan to have a trunk alpha. The 1.8 branch branched on August 12,
> 2005; tomorrow it will be 8 months since that day. That's 8 months of trunk
> development already; for comparison, by this point in the 1.8 Gecko cycle we had
> already done the 1.8a5 release. Granted, the alphas weren't getting much
> testing because of all the effort focused on Aviary, but we _did_ see a spike in
> useful bug reports around each alpha being released.
>
> I'm not sure what the thinking is about checkpointing trunk and calling it an
> alpha and what the build team costs of doing an alpha release are, but I can
> understand us not wanting to ship an alpha quite yet. At the same time, we've
> made some pretty big changes (DOM event dispatch, frame display lists, 2/3 of
> cairo) that could use testing.
I'm in favor of checkpointing the trunk with an alpha release sooner
rather than later. I think it will depend greatly on release
engineering since they are still busy with the many sustaining
branches.
> We probably shouldn't ship an alpha until we turn on cairo by default on Mac.
> But after that (hopefully soon?) point, what else do we need or want to wait
> for? What other large projects are scheduled for 1.9 at this point? I can
> think of reflow branch, view removal, widget removal, nsTextFrame rewrite, gfx
> removal off the top of my head. Do we want all those done before we ship an
> alpha? Or some subset of those? Are we OK with landing some of these after the
> first alpha (and do we plan to have multiple alpha releases)? Are there things
> I'm forgetting?
I hope to have the Thread Manager changes (bug 326273) in shortly. I
think the patch is likely to cause some regressions ;-)
> One last note: naming. I have no particular yen to have this be named "Firefox
> 3 Alpha 1". Let's make up a codename if we don't have one yet and ship this as
> "Codename Developer Preview 1" or something. Make it clear that this is
> pre-alpha (not all large features done) and list the specific large changes we
> made that we'd like testing from web developers on...
I thought a name was already chosen and implemented... "minefield":
http://www.beltzner.ca/mike/archives/2006/04/11/expect_an_earthshattering_kaboom.html
-Darin
Mike Beltzner
Yup; to be clear, though, the idea is that "Minefield" isn't
associated with any target deliverable, but is the name which we use
to refer to builds that come off the trunk. So, when the trunk is
branched for Firefox 3, for example, we'd rename the builds on that
branch to use the codename for Firefox 3 (whatever that ends up
being).
cheers,
mike
--
[ mike beltzner / user experience lead / mozilla corporation ]
Boris Zbarsky
-------- Original Message --------
Subject: Re: Scheduling a trunk alpha
Date: Wed, 12 Apr 2006 19:05:40 -0700
From: Jonas Sicking <jonas....@me.sicking.cc>
Newsgroups: mozilla.dev.platform
References: <LKGdnYIE__jFTabZ...@mozilla.org>
There are a few things that I think are important.
First of all I'm worried about confusion if we release a FF 3 alpha
before FF 2 is out the door. However, this problem would be lessened a
lot, or even go away, if we name the release something other then
"Firefox 3 alpha".
Second, I think we need to make sure we get the right people to download
and test this thing. We have had a problem in the past with people not
testing heavily until it's too late to actually fix bad regressions.
Unfortunately I don't really have a good answer to this one, other than
possibly saying "don't spend time on too many alphas that don't get
heavy testing anyway". Really, do we get a lot of people testing alphas
that aren't already testing nightlies?
Lastly, I think deciding on an aimed release date is the first thing we
should do since without that anything we do is likely too early or too
late. We probably don't need to hammer out an exact date, but within a
month or two seems resonable.
/ Jonas
Neil
>>I thought a name was already chosen and implemented... "minefield":
>>
>>
>Yup; to be clear, though, the idea is that "Minefield" isn't associated with any target deliverable, but is the name which we use to refer to builds that come off the trunk.
>
So you could just have arbitrarily numbered Minefield builds that won't
directly relate to any other releases. You could even restart the old M
numbering ;-)
--
Warning: May contain traces of nuts.
Michael Lefevre
>> I thought a name was already chosen and implemented... "minefield":
>
> Yup; to be clear, though, the idea is that "Minefield" isn't
> associated with any target deliverable, but is the name which we use
> to refer to builds that come off the trunk.
This may be getting too technical (particularly from someone who isn't a
developer), but that seems to make the assumption that there will be no
target deliverables which are trunk builds. I don't know if making
branches for things is better than rebranding/reversioning trunk (before
and after a release), but both of those things have taken time to happen
in the past and led to confusion...
--
Michael
Mike Connor
Making branches makes sense if Gecko v.next is sufficiently cleaned up.
How we ensure that's the case is a different question, of course, but
one that needs solving to make branch-based Firefox alphas even
appropriate, let alone desirable.
-- Mike