[Fwd: Re: Scheduling a trunk alpha]

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Fwd: Re: Scheduling a trunk alpha]

Boris Zbarsky
Reposting from .platform

-------- Original Message --------
From: Darin Fisher <[hidden email]>
Newsgroups: mozilla.dev.platform

On 4/11/06, Boris Zbarsky <[hidden email]> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: Scheduling a trunk alpha]

beltzner
> 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, 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 ]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: Scheduling a trunk alpha]

Neil-4
In reply to this post by Boris Zbarsky
Mike Beltzner wrote:

>>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.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: Scheduling a trunk alpha]

Michael Lefevre
In reply to this post by Boris Zbarsky
On 2006-04-12, Mike Beltzner <[hidden email]> wrote:
>> 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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: [Fwd: Re: Scheduling a trunk alpha]

Mike Connor-3
Michael Lefevre wrote:

> On 2006-04-12, Mike Beltzner <[hidden email]> wrote:
>>> 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...

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
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning