Thoughs on 1.9, 1.9.1, and 2

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

Thoughs on 1.9, 1.9.1, and 2

Vladimir Vukicevic-3
One of the common discussions that seems to come up often is what
happens when 1.9 is done: do we go full-bore on 2?  Do we plan for an
interim release?  Do we have a way of fixing small polish/regression
bugs that we weren't able to get to 1.9 before the next major release?

The main thing I'll assert here is that I think it is vitally
important that the entire engineering team commits fully to work that
will benefit whatever initial release "Mozilla 2" becomes: being able
to make API-breaking changes, architectural improvements, potentially
doing some of the large changes such as XPCOM GC, Tamarin, etc.
However, I believe that there is a large set of changes and features
that are important for us to work on that don't require or impact Moz
2 at all; for example (from areas that I'm most familiar with),
<video> support, improvements to SVG, downloadable fonts, CSS
border-image, etc.  So, I'd like to propose the following plan:

<http://people.mozilla.com/~vladimir/misc/branch-moz2.svg>

I'm pretty sure the things in green and orange are not controversial;
we will obviously do security fixes for issues as they come up for
1.9.0.x, mobile work will be ongoing with 1.9, and for Moz 2, all
those things I named above will be happening.

The items in yellow are, I think, what a lot of people are pondering
right now.  I think that there is room for a 1.9.1 release on a very
quick cycle -- 6 months probably at the longest.  I would suggest that
for regular 1.9.0.x maintenance releases, in addition to taking
security fixes, we also take well-tested and low-impact regression
fixes, and possibly very small isolated features.  Both of these
should have no impact on Mozilla 2 to be worked on -- that is, they
should be equally relevant to 1.9 as they would to Moz 2.  (For
example, CSS border-image would be a feature that I think could go
into a 1.9.0.x release.)

1.9.1 would include feature work that is of more moderate size, but
again, that applies equally to 1.9 and 2.  <video> is a good example;
the compositor work is not.  Some of these features will definitely
have overhead in ensuring that they fit in both 1.9 and Moz 2
codebase; if that overhead becomes high, the feature should be cut
from 1.9.1.  I've also placed additional work for mobile in the 1.9.1
column; it seems natural that any mobile development will (at some
point) want to have a "release" branch, and not just be 1.9.0.x +
various patches.

There are costs with doing the 1.9.1 release: mainly triage, build,
and QA work, so it's not entirely free.  Developer costs would also
exist, but I think that if they are manageable, doing a 1.9.1 release
would be valuable.  Much like features for which developer overhead
becomes too high for 1.9 and Moz 2 implementation, 1.9.1 should be an
opportunistic release: I think we should plan on it, but if it doesn't
look like we can deliver a compelling 1.9.1 within some small number
of months after 1.9 release, we should cut 1.9.1 (and the associated
release overhead) and focus entirely on Mozilla 2.

Incidentally, this is speaking entirely from a platform point of view;
I think a 1.9.1 would be valuable both for the Firefox front end (for
all the front end work that we didn't have time for in Fx 3) and for
other applications that build on top of Gecko (both for taking
advantage of new Gecko 1.9 features, and for fixing
application-specfici regressions).

Thoughts?

    - Vlad

--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo

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

Re: Thoughs on 1.9, 1.9.1, and 2

Mike Beltzner
> Thoughts?

Lots!

I think you've captured things well from a platform development
perspective, in terms of making sure that if we dare to once again split
our focus between three branches (1.9.0.x / 1.9 / moz2) we do so knowing
full well how that will affect the quality and speed at which we can
deliver products. And actually, we shouldn't neglect to realize that
until at least 6 months after the release of Firefox 3 we're actually
talking about keeping four branches (1.8.1.x / 1.9.0.1 / 1.9 / moz2) in
development.

 From a product delivery / front-end side of things, though, I want to
make sure that we evaluate the worth of a 1.9.1 release based on the
opportunities and costs involved. To do this I'd love to get a set of
guesses at timelines sketched out to help us decide when we'd need to be
pushing out a 1.9.1-based product in order to be useful to our various
consumers (users, website authors, add-on authors / platform consumers)
and whether or not we can deliver the content required to make that
release meaningful. I think that would help answer some of the scoping
questions you raise.

My proposal for how to do this would be to try and coarsely describe the
various areas of development (as a first try: performance, platform
capability, platform architecture, security, UI feature development) and
build roadmaps that take into account where we want to take things in
the near and long term futures, and where the various competitor and
community ecosystems are going in terms of standards, specifications,
etc. I'm not sure who the right people are to help, here, but I fear
that a lot of them are the same ones who are heads down working on
delivering Firefox 3.

Finally, while I'd encourage people looking at that thread to absolutely
start thinking about the points made, I don't think people should worry
about having to drop what they're doing to answer this post now, or to
answer these questions now. I definitely agree that we need to figure
out how and when we'll get those answers, but think that the best time
to target for that is "after RC1", at least :)

cheers,
mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Stuart Parmenter-3
In reply to this post by Vladimir Vukicevic-3
On Mar 6, 5:50 pm, Vladimir Vukicevic <[hidden email]> wrote:
> I'm pretty sure the things in green and orange are not controversial;
> we will obviously do security fixes for issues as they come up for
> 1.9.0.x, mobile work will be ongoing with 1.9, and for Moz 2, all
> those things I named above will be happening.
>

I very strongly disagree with the idea of doing a 1.9.1 (at all) on a
short cycle.  We should instead focus on doing a Mozilla 2 (all this
means is breaking APIs) on a short schedule instead.  We can do the
same set of work you suggest and break a few APIs. This means we no
longer have to keep the same API compatibility promises we've made in
the past which are holding us back in many ways.  I'm of the opinion
that we probably won't be able to land MMGC, Tamarin, etc in this
short time frame but that people should continue working on them.

I think we should be looking at more of a 12 month schedule.  We
likely need that much time to get a compelling Firefox release out.  I
also don't see any advantage to doing a 1.9.1 release.  All I see is
it splitting up the team and requiring people working on 4 (1.9,
1.9.1, 2, 2.1?) releases simultaneously.  It is hard enough to ship 1
release with everyone on board.  Lets leverage the people we have and
focus on a solid release.

stuart
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Robert Kaiser
In reply to this post by Vladimir Vukicevic-3
Vladimir Vukicevic wrote:
> The main thing I'll assert here is that I think it is vitally
> important that the entire engineering team commits fully to work that
> will benefit whatever initial release "Mozilla 2" becomes

I guess you mean the platform developers only here, as from what I see,
Moz2 is not nearly fit for anything else than in-deep platform
development right now, and esp. not for anything else than Firefox on
top of it, as:
1) Most other apps are not even near to anything shippable on 1.9.
2) There's a lot in flux of what Moz2 will even look like.
3) any app code developed on top of current Moz2 probably needs to be
rewritten 2-3 times before the platform gets nearly usable.
4) The toolchain for apps outside mozilla-central is completely
unresolved, there isn't nearly a solution for this yet.
5) There's no guesstimate how long the Moz2 dev cycle could be, we might
not see a stable release in this century.

In that light, I think your proposal for 1.9.1 sounds reasonable, though
I know a certain amount of people starts to shudder when thinking we
might get a similar situation as for 1.7/1.8.0/1.8.1/1.9 parallel
development/maintenance.

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Mike Shaver
In reply to this post by Vladimir Vukicevic-3
On Thu, Mar 6, 2008 at 8:50 PM, Vladimir Vukicevic <[hidden email]> wrote:
>  I would suggest that
>  for regular 1.9.0.x maintenance releases, in addition to taking
>  security fixes, we also take well-tested and low-impact regression
>  fixes, and possibly very small isolated features.

I don't think they need to be very small (and don't want to get into
fights about what "very small" is, much as I love a good fight), but I
do think they need to be isolated.  And I won't settle for "possibly".

>  Both of these
>  should have no impact on Mozilla 2 to be worked on -- that is, they
>  should be equally relevant to 1.9 as they would to Moz 2.  (For
>  example, CSS border-image would be a feature that I think could go
>  into a 1.9.0.x release.)

I think we should do things that are 1.9.0.x-capable (meaning
well-scoped, additive, backward-compatible, isolated, have solid test
suites, cleanly object-detectable) and we should do things for Mozilla
2, but I don't think we should do platform features that are in the
middle.  Mozilla 2 can't be an experimental playground, it needs to be
a place where things are pushed to product-quality completeness as
dominant model, so that we stay close to being ship-ready and don't
end up off in the weeds for 18, no 24, no 30 months trying to converge
on a product state.

>  1.9.1 would include feature work that is of more moderate size, but
>  again, that applies equally to 1.9 and 2.  <video> is a good example;
>  the compositor work is not.

<video> in 1.9.0.x.  Worker threads in 1.9.0.x.  querySelector in
1.9.0.x.  Content-exposed JSON in 1.9.0.x.  Follow-on XS-XHR in
1.9.0.x.  Compatible ES4 features that are spec-stable enough in
1.9.0.x.  Scriptable plugin API features in 1.9.0.x.  Cairo tracking
for perf and rendering quality in 1.9.0.x.  SRP in 1.9.0.x.

Compositor in 2.  XPCOMGC in 2.  Tamarin-or-a-hand-drawn-facsimile in
2.  A complete RDFectomy in 2.  SVG architecture work for size and
speed in 2.  Fixing file-launch and web-protocol integration to not
hurt, probably in 2, because I can't see doing it extension-compatibly
unless someone really leans into that test framework.

(And by "2" I mean "2 or later", not that I would block for all of those.)

I would much much rather trickle in capabilities along the 1.9.0.x
series as their ready than try to wrap them all up into a unified
middling-bang release.  It lets us take features when they're ready,
reduces the risk of "I'll figure out that edge case when we get closer
to release" or "ah, since there's another 2 months until freeze, I'll
put in something else!".

Means we'd need a beta or Technology Preview channel for people to
test against, with these (isolated, remember) 1.9.0.x-grade features
promoted to them when they reached beta state.  Well-understood
problem, I think.

>  Incidentally, this is speaking entirely from a platform point of view;
>  I think a 1.9.1 would be valuable both for the Firefox front end (for
>  all the front end work that we didn't have time for in Fx 3) and for
>  other applications that build on top of Gecko (both for taking
>  advantage of new Gecko 1.9 features, and for fixing
>  application-specfici regressions).

Firefox compat is a different calculus, I think: harder for the app to
do anything interesting without breaking extension compat; easy for it
to do a lot of stuff without breaking content compatibility.

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Doug Turner-2
In reply to this post by Vladimir Vukicevic-3
I agree with Mobile using a 1.9 CVS branch.


On Mar 6, 2008, at 5:50 PM, Vladimir Vukicevic wrote:

> One of the common discussions that seems to come up often is what
> happens when 1.9 is done: do we go full-bore on 2?  Do we plan for an
> interim release?  Do we have a way of fixing small polish/regression
> bugs that we weren't able to get to 1.9 before the next major release?
>
> The main thing I'll assert here is that I think it is vitally
> important that the entire engineering team commits fully to work that
> will benefit whatever initial release "Mozilla 2" becomes: being able
> to make API-breaking changes, architectural improvements, potentially
> doing some of the large changes such as XPCOM GC, Tamarin, etc.
> However, I believe that there is a large set of changes and features
> that are important for us to work on that don't require or impact Moz
> 2 at all; for example (from areas that I'm most familiar with),
> <video> support, improvements to SVG, downloadable fonts, CSS
> border-image, etc.  So, I'd like to propose the following plan:
>
> <http://people.mozilla.com/~vladimir/misc/branch-moz2.svg>
>
> I'm pretty sure the things in green and orange are not controversial;
> we will obviously do security fixes for issues as they come up for
> 1.9.0.x, mobile work will be ongoing with 1.9, and for Moz 2, all
> those things I named above will be happening.
>
> The items in yellow are, I think, what a lot of people are pondering
> right now.  I think that there is room for a 1.9.1 release on a very
> quick cycle -- 6 months probably at the longest.  I would suggest that
> for regular 1.9.0.x maintenance releases, in addition to taking
> security fixes, we also take well-tested and low-impact regression
> fixes, and possibly very small isolated features.  Both of these
> should have no impact on Mozilla 2 to be worked on -- that is, they
> should be equally relevant to 1.9 as they would to Moz 2.  (For
> example, CSS border-image would be a feature that I think could go
> into a 1.9.0.x release.)
>
> 1.9.1 would include feature work that is of more moderate size, but
> again, that applies equally to 1.9 and 2.  <video> is a good example;
> the compositor work is not.  Some of these features will definitely
> have overhead in ensuring that they fit in both 1.9 and Moz 2
> codebase; if that overhead becomes high, the feature should be cut
> from 1.9.1.  I've also placed additional work for mobile in the 1.9.1
> column; it seems natural that any mobile development will (at some
> point) want to have a "release" branch, and not just be 1.9.0.x +
> various patches.
>
> There are costs with doing the 1.9.1 release: mainly triage, build,
> and QA work, so it's not entirely free.  Developer costs would also
> exist, but I think that if they are manageable, doing a 1.9.1 release
> would be valuable.  Much like features for which developer overhead
> becomes too high for 1.9 and Moz 2 implementation, 1.9.1 should be an
> opportunistic release: I think we should plan on it, but if it doesn't
> look like we can deliver a compelling 1.9.1 within some small number
> of months after 1.9 release, we should cut 1.9.1 (and the associated
> release overhead) and focus entirely on Mozilla 2.
>
> Incidentally, this is speaking entirely from a platform point of view;
> I think a 1.9.1 would be valuable both for the Firefox front end (for
> all the front end work that we didn't have time for in Fx 3) and for
> other applications that build on top of Gecko (both for taking
> advantage of new Gecko 1.9 features, and for fixing
> application-specfici regressions).
>
> Thoughts?
>
>    - Vlad
>
> --
> I'm trying a new usenet client for Mac, Nemo OS X.
> You can download it at http://www.malcom-mac.com/nemo
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

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

Re: Thoughs on 1.9, 1.9.1, and 2

Mike Shaver
On Fri, Mar 7, 2008 at 10:25 AM, Doug Turner <[hidden email]> wrote:
> I agree with Mobile using a 1.9 CVS branch.

Is that because you've been having problems with Mercurial, or because
you want to be able to make possibly-destabilizing (and therefore
1.9.0.x-ineligible) changes?  Why wouldn't you want to integrate early
and often, and get your test cases into the critical path for others
working on the core code?

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Mike Connor-4
In reply to this post by Vladimir Vukicevic-3
I don't think that's a stated goal, or ideal for our purposes...

- Mike

----- Original Message -----
From: [hidden email]
<[hidden email]>
To: Vladimir Vukicevic <[hidden email]>
Cc: [hidden email] <[hidden email]>
Sent: Fri Mar 07 07:25:30 2008
Subject: Re: Thoughs on 1.9, 1.9.1, and 2

I agree with Mobile using a 1.9 CVS branch.


On Mar 6, 2008, at 5:50 PM, Vladimir Vukicevic wrote:

> One of the common discussions that seems to come up often is what
> happens when 1.9 is done: do we go full-bore on 2?  Do we plan for an
> interim release?  Do we have a way of fixing small polish/regression
> bugs that we weren't able to get to 1.9 before the next major release?
>
> The main thing I'll assert here is that I think it is vitally
> important that the entire engineering team commits fully to work that
> will benefit whatever initial release "Mozilla 2" becomes: being able
> to make API-breaking changes, architectural improvements, potentially
> doing some of the large changes such as XPCOM GC, Tamarin, etc.
> However, I believe that there is a large set of changes and features
> that are important for us to work on that don't require or impact Moz
> 2 at all; for example (from areas that I'm most familiar with),
> <video> support, improvements to SVG, downloadable fonts, CSS
> border-image, etc.  So, I'd like to propose the following plan:
>
> <http://people.mozilla.com/~vladimir/misc/branch-moz2.svg>
>
> I'm pretty sure the things in green and orange are not controversial;
> we will obviously do security fixes for issues as they come up for
> 1.9.0.x, mobile work will be ongoing with 1.9, and for Moz 2, all
> those things I named above will be happening.
>
> The items in yellow are, I think, what a lot of people are pondering
> right now.  I think that there is room for a 1.9.1 release on a very
> quick cycle -- 6 months probably at the longest.  I would suggest that
> for regular 1.9.0.x maintenance releases, in addition to taking
> security fixes, we also take well-tested and low-impact regression
> fixes, and possibly very small isolated features.  Both of these
> should have no impact on Mozilla 2 to be worked on -- that is, they
> should be equally relevant to 1.9 as they would to Moz 2.  (For
> example, CSS border-image would be a feature that I think could go
> into a 1.9.0.x release.)
>
> 1.9.1 would include feature work that is of more moderate size, but
> again, that applies equally to 1.9 and 2.  <video> is a good example;
> the compositor work is not.  Some of these features will definitely
> have overhead in ensuring that they fit in both 1.9 and Moz 2
> codebase; if that overhead becomes high, the feature should be cut
> from 1.9.1.  I've also placed additional work for mobile in the 1.9.1
> column; it seems natural that any mobile development will (at some
> point) want to have a "release" branch, and not just be 1.9.0.x +
> various patches.
>
> There are costs with doing the 1.9.1 release: mainly triage, build,
> and QA work, so it's not entirely free.  Developer costs would also
> exist, but I think that if they are manageable, doing a 1.9.1 release
> would be valuable.  Much like features for which developer overhead
> becomes too high for 1.9 and Moz 2 implementation, 1.9.1 should be an
> opportunistic release: I think we should plan on it, but if it doesn't
> look like we can deliver a compelling 1.9.1 within some small number
> of months after 1.9 release, we should cut 1.9.1 (and the associated
> release overhead) and focus entirely on Mozilla 2.
>
> Incidentally, this is speaking entirely from a platform point of view;
> I think a 1.9.1 would be valuable both for the Firefox front end (for
> all the front end work that we didn't have time for in Fx 3) and for
> other applications that build on top of Gecko (both for taking
> advantage of new Gecko 1.9 features, and for fixing
> application-specfici regressions).
>
> Thoughts?
>
>    - Vlad
>
> --
> I'm trying a new usenet client for Mac, Nemo OS X.
> You can download it at http://www.malcom-mac.com/nemo
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning

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

Re: Thoughs on 1.9, 1.9.1, and 2

Benjamin Smedberg
In reply to this post by Vladimir Vukicevic-3
I agree with Stuart/shaver in general, with some additional thoughts:

* I am especially concerned about splitting our testing resources three
ways. Not just employed QA, but our nightly tester community is an
especially valuable resource. 1.9 didn't get much nightly testing for a long
time while 1.8.1 was going on, partly because of the places debacle.

* I think we should be more lenient about changing internal APIs in 1.9.0.x,
as I posted recently in dev.platform. This should make it easier to
integrate new content-facing features such as video/cross-site XHR, etc
directly into 1.9.0.x rather than an in-between spot

* Mozilla 2 is a chance to break APIs. It is not a place to take massive
instability. I think that, whatever schedule we pick, we should require
mozilla-central to be in a shippable state all the time.

** Unit testing certainly helps with this
** as well as a willingness to aggressively back out things as regressions
are found (no more half-baked threadmanager)
** So does the distributed-branching model: we have most of the
infrastructure in place now to produce builds, perftest, and unit-test
feature branches for long periods of time before they are merged

I think we come up with an arbitrary metric that mozilla-central is "21 days
from beta" all the time. I'm wondering if it's possible to introduce a
lightweight continuous-driving process which can keep us in a
constant-quality state and provoke the aggressive backouts needed to keep
quality.

The danger is this is that we'd never be able to land large features which
by their nature require more than 3 weeks of regression-fix time. Looking
back on 1.9 with the promise of better distributed-branches tooling, do you
think we could have landed cocoa widgets, cairo, places, threadmanager, or
the reflow branch with less than 3 weeks of regressions? Or that we will be
able to land XPCOMGC, (Tamarin) tracing, or compositor in 2.0 with less than
3 weeks of regressions?

If we can, then we can make decisions about when to ship much later than we
have... start doing work, and when the trunk seems suitably better than our
current release, decide that we're going to do the Firefox 4 beta in a
month, with another month of RCs for a total time-to-ship of 8 weeks.

--BDS
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Doug Turner-2
In reply to this post by Mike Shaver

On Mar 7, 2008, at 7:45 AM, Mike Shaver wrote:

> On Fri, Mar 7, 2008 at 10:25 AM, Doug Turner <[hidden email]>  
> wrote:
>> I agree with Mobile using a 1.9 CVS branch.
>
> Is that because you've been having problems with Mercurial, or because
> you want to be able to make possibly-destabilizing (and therefore
> 1.9.0.x-ineligible) changes?  Why wouldn't you want to integrate early
> and often, and get your test cases into the critical path for others
> working on the core code?
>
> Mike


Mike,

We want to ship something this year.  It looks like 1.9 is the vehicle  
to do just that.  Am I missing something?

Doug

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

Re: Thoughs on 1.9, 1.9.1, and 2

Doug Turner-2
In reply to this post by Mike Connor-4
i just stated it as a goal. :-)

What purposes are you talking about?


On Mar 7, 2008, at 7:57 AM, Mike Connor wrote:

> I don't think that's a stated goal, or ideal for our purposes...
>
> - Mike
>
> ----- Original Message -----
> From: [hidden email] <[hidden email]
> >
> To: Vladimir Vukicevic <[hidden email]>
> Cc: [hidden email] <[hidden email]>
> Sent: Fri Mar 07 07:25:30 2008
> Subject: Re: Thoughs on 1.9, 1.9.1, and 2
>
> I agree with Mobile using a 1.9 CVS branch.
>
>
> On Mar 6, 2008, at 5:50 PM, Vladimir Vukicevic wrote:
>
> > One of the common discussions that seems to come up often is what
> > happens when 1.9 is done: do we go full-bore on 2?  Do we plan for  
> an
> > interim release?  Do we have a way of fixing small polish/regression
> > bugs that we weren't able to get to 1.9 before the next major  
> release?
> >
> > The main thing I'll assert here is that I think it is vitally
> > important that the entire engineering team commits fully to work  
> that
> > will benefit whatever initial release "Mozilla 2" becomes: being  
> able
> > to make API-breaking changes, architectural improvements,  
> potentially
> > doing some of the large changes such as XPCOM GC, Tamarin, etc.
> > However, I believe that there is a large set of changes and features
> > that are important for us to work on that don't require or impact  
> Moz
> > 2 at all; for example (from areas that I'm most familiar with),
> > <video> support, improvements to SVG, downloadable fonts, CSS
> > border-image, etc.  So, I'd like to propose the following plan:
> >
> > <http://people.mozilla.com/~vladimir/misc/branch-moz2.svg>
> >
> > I'm pretty sure the things in green and orange are not  
> controversial;
> > we will obviously do security fixes for issues as they come up for
> > 1.9.0.x, mobile work will be ongoing with 1.9, and for Moz 2, all
> > those things I named above will be happening.
> >
> > The items in yellow are, I think, what a lot of people are pondering
> > right now.  I think that there is room for a 1.9.1 release on a very
> > quick cycle -- 6 months probably at the longest.  I would suggest  
> that
> > for regular 1.9.0.x maintenance releases, in addition to taking
> > security fixes, we also take well-tested and low-impact regression
> > fixes, and possibly very small isolated features.  Both of these
> > should have no impact on Mozilla 2 to be worked on -- that is, they
> > should be equally relevant to 1.9 as they would to Moz 2.  (For
> > example, CSS border-image would be a feature that I think could go
> > into a 1.9.0.x release.)
> >
> > 1.9.1 would include feature work that is of more moderate size, but
> > again, that applies equally to 1.9 and 2.  <video> is a good  
> example;
> > the compositor work is not.  Some of these features will definitely
> > have overhead in ensuring that they fit in both 1.9 and Moz 2
> > codebase; if that overhead becomes high, the feature should be cut
> > from 1.9.1.  I've also placed additional work for mobile in the  
> 1.9.1
> > column; it seems natural that any mobile development will (at some
> > point) want to have a "release" branch, and not just be 1.9.0.x +
> > various patches.
> >
> > There are costs with doing the 1.9.1 release: mainly triage, build,
> > and QA work, so it's not entirely free.  Developer costs would also
> > exist, but I think that if they are manageable, doing a 1.9.1  
> release
> > would be valuable.  Much like features for which developer overhead
> > becomes too high for 1.9 and Moz 2 implementation, 1.9.1 should be  
> an
> > opportunistic release: I think we should plan on it, but if it  
> doesn't
> > look like we can deliver a compelling 1.9.1 within some small number
> > of months after 1.9 release, we should cut 1.9.1 (and the associated
> > release overhead) and focus entirely on Mozilla 2.
> >
> > Incidentally, this is speaking entirely from a platform point of  
> view;
> > I think a 1.9.1 would be valuable both for the Firefox front end  
> (for
> > all the front end work that we didn't have time for in Fx 3) and for
> > other applications that build on top of Gecko (both for taking
> > advantage of new Gecko 1.9 features, and for fixing
> > application-specfici regressions).
> >
> > Thoughts?
> >
> >    - Vlad
> >
> > --
> > I'm trying a new usenet client for Mac, Nemo OS X.
> > You can download it at http://www.malcom-mac.com/nemo
> >
> > _______________________________________________
> > dev-planning mailing list
> > [hidden email]
> > https://lists.mozilla.org/listinfo/dev-planning
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>

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

Re: Thoughs on 1.9, 1.9.1, and 2

Doug Turner-2
In reply to this post by Mike Connor-4
Oh, the CVS part appears to be controversial!  So assuming that all of  
the tools work, i do not care what the VCS is.  I would like to stick  
with CVS because everyone knows how to use it, but if mozilla is going  
to switch, great.


On Mar 7, 2008, at 7:57 AM, Mike Connor wrote:

> I don't think that's a stated goal, or ideal for our purposes...
>
> - Mike
>
> ----- Original Message -----
> From: [hidden email] <[hidden email]
> >
> To: Vladimir Vukicevic <[hidden email]>
> Cc: [hidden email] <[hidden email]>
> Sent: Fri Mar 07 07:25:30 2008
> Subject: Re: Thoughs on 1.9, 1.9.1, and 2
>
> I agree with Mobile using a 1.9 CVS branch.
>
>
> On Mar 6, 2008, at 5:50 PM, Vladimir Vukicevic wrote:
>
> > One of the common discussions that seems to come up often is what
> > happens when 1.9 is done: do we go full-bore on 2?  Do we plan for  
> an
> > interim release?  Do we have a way of fixing small polish/regression
> > bugs that we weren't able to get to 1.9 before the next major  
> release?
> >
> > The main thing I'll assert here is that I think it is vitally
> > important that the entire engineering team commits fully to work  
> that
> > will benefit whatever initial release "Mozilla 2" becomes: being  
> able
> > to make API-breaking changes, architectural improvements,  
> potentially
> > doing some of the large changes such as XPCOM GC, Tamarin, etc.
> > However, I believe that there is a large set of changes and features
> > that are important for us to work on that don't require or impact  
> Moz
> > 2 at all; for example (from areas that I'm most familiar with),
> > <video> support, improvements to SVG, downloadable fonts, CSS
> > border-image, etc.  So, I'd like to propose the following plan:
> >
> > <http://people.mozilla.com/~vladimir/misc/branch-moz2.svg>
> >
> > I'm pretty sure the things in green and orange are not  
> controversial;
> > we will obviously do security fixes for issues as they come up for
> > 1.9.0.x, mobile work will be ongoing with 1.9, and for Moz 2, all
> > those things I named above will be happening.
> >
> > The items in yellow are, I think, what a lot of people are pondering
> > right now.  I think that there is room for a 1.9.1 release on a very
> > quick cycle -- 6 months probably at the longest.  I would suggest  
> that
> > for regular 1.9.0.x maintenance releases, in addition to taking
> > security fixes, we also take well-tested and low-impact regression
> > fixes, and possibly very small isolated features.  Both of these
> > should have no impact on Mozilla 2 to be worked on -- that is, they
> > should be equally relevant to 1.9 as they would to Moz 2.  (For
> > example, CSS border-image would be a feature that I think could go
> > into a 1.9.0.x release.)
> >
> > 1.9.1 would include feature work that is of more moderate size, but
> > again, that applies equally to 1.9 and 2.  <video> is a good  
> example;
> > the compositor work is not.  Some of these features will definitely
> > have overhead in ensuring that they fit in both 1.9 and Moz 2
> > codebase; if that overhead becomes high, the feature should be cut
> > from 1.9.1.  I've also placed additional work for mobile in the  
> 1.9.1
> > column; it seems natural that any mobile development will (at some
> > point) want to have a "release" branch, and not just be 1.9.0.x +
> > various patches.
> >
> > There are costs with doing the 1.9.1 release: mainly triage, build,
> > and QA work, so it's not entirely free.  Developer costs would also
> > exist, but I think that if they are manageable, doing a 1.9.1  
> release
> > would be valuable.  Much like features for which developer overhead
> > becomes too high for 1.9 and Moz 2 implementation, 1.9.1 should be  
> an
> > opportunistic release: I think we should plan on it, but if it  
> doesn't
> > look like we can deliver a compelling 1.9.1 within some small number
> > of months after 1.9 release, we should cut 1.9.1 (and the associated
> > release overhead) and focus entirely on Mozilla 2.
> >
> > Incidentally, this is speaking entirely from a platform point of  
> view;
> > I think a 1.9.1 would be valuable both for the Firefox front end  
> (for
> > all the front end work that we didn't have time for in Fx 3) and for
> > other applications that build on top of Gecko (both for taking
> > advantage of new Gecko 1.9 features, and for fixing
> > application-specfici regressions).
> >
> > Thoughts?
> >
> >    - Vlad
> >
> > --
> > I'm trying a new usenet client for Mac, Nemo OS X.
> > You can download it at http://www.malcom-mac.com/nemo
> >
> > _______________________________________________
> > dev-planning mailing list
> > [hidden email]
> > https://lists.mozilla.org/listinfo/dev-planning
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>

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

Re: Thoughs on 1.9, 1.9.1, and 2

Boris Zbarsky
In reply to this post by Vladimir Vukicevic-3
Mike Shaver wrote:
> <video> in 1.9.0.x.  Worker threads in 1.9.0.x.  querySelector in
> 1.9.0.x.  Content-exposed JSON in 1.9.0.x.  Follow-on XS-XHR in
> 1.9.0.x.  Compatible ES4 features that are spec-stable enough in
> 1.9.0.x.  Scriptable plugin API features in 1.9.0.x.  Cairo tracking
> for perf and rendering quality in 1.9.0.x.  SRP in 1.9.0.x.

I'm assuming we're up for arguments about the suitability of some of these
(worker threads jumps out at me) for a stable release?  I agree that some of
these others ought to be safe enough to add in a 1.9.0.x release, but see below.

If we do this sort of thing we'll need a much better testing (not just
automated, but user testing) and regression-fixing story than we've had with the
1.8.0 and 1.8.1 branches... but I'm assuming that's part of the plan anyway.

One issue I worry about here is that some of these changes could in fact affect
web compat.  querySelector, ES4 things.  They shouldn't, but I won't bet there
is NO site out there that uses a function called querySelector that they attach
to nodes.  See the issues we ran into with getElementsByClassName, some of which
are still pending evangelism action.  While we may be willing to take the
potential compat hit, it's worth checking on our various distributors (on Linux,
basically, since we do our own thing on Window/Mac).  Are they willing to go
with that approach?  Or are they going to start cherry-picking security fixes
but avoiding the feature ones?  That's a path we'd all like to avoid, I think.

If we can swing it, I'd definitely prefer this approach to a 1.9.1 release,
because the things you list have vastly different development times.  For
example, querySelector and a lot of the remaining CSS3 selectors can probably be
wrapped up in 2 weeks.  I doubt <video> is that close to be being done, for example.

-Boris
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Mike Shaver
In reply to this post by Doug Turner-2
On Fri, Mar 7, 2008 at 11:31 AM, Doug Turner <[hidden email]> wrote:
> We want to ship something this year.  It looks like 1.9 is the vehicle
> to do just that.  Am I missing something?

Are you talking about a mobile-specific branch, or shipping off the
1.9 branch?  We very much plan to ship off the 1.9 stream multiple
times this year, so that alone isn't reason enough to be on a
mobile-specific branch.

I haven't looked at the mobile roadmap to see what the disruptive
changes are, or what the level of confidence is tests to back up
whatever mobile-oriented changes land, so I don't know much about what
your other constraints are.  Can you be more explicit?

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Doug Turner-2
i am not expecting to be on a mobile-specific branch.  Ideally, what  
we are planning for this year doesn't require large changes on to  
1.9.  If we are wrong, we would switch over to Moz2.

On Mar 7, 2008, at 9:40 AM, Mike Shaver wrote:

> On Fri, Mar 7, 2008 at 11:31 AM, Doug Turner <[hidden email]>  
> wrote:
>> We want to ship something this year.  It looks like 1.9 is the  
>> vehicle
>> to do just that.  Am I missing something?
>
> Are you talking about a mobile-specific branch, or shipping off the
> 1.9 branch?  We very much plan to ship off the 1.9 stream multiple
> times this year, so that alone isn't reason enough to be on a
> mobile-specific branch.
>
> I haven't looked at the mobile roadmap to see what the disruptive
> changes are, or what the level of confidence is tests to back up
> whatever mobile-oriented changes land, so I don't know much about what
> your other constraints are.  Can you be more explicit?
>
> Mike

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

Re: Thoughts on 1.9, 1.9.1, and 2

Vladimir Vukicevic-3
In reply to this post by Benjamin Smedberg
In article <[hidden email]>
BenjaminSmedberg <[hidden email]> wrote:
>  * Mozilla 2 is a chance to break APIs. It is not a place to take
> massive instability. I think that, whatever schedule we pick, we
> should require mozilla-central to be in a shippable state all the
>  time.

I don't think there will be massive code/crashyness instability (I
agree with your "21 days from beta" suggestion), but there will be
massive platform API churn that people will be playing catchup to.
>  Unit testing certainly helps with this
>  as well as a willingness to aggressively back out things as
> regressions are found (no more half-baked threadmanager)
>  ** So does the distributed-branching model: we have most of the
> infrastructure in place now to produce builds, perftest, and
> unit-test feature branches for long periods of time before they are
>  merged

Yep, I think this is going to be key for anything we do, whether it's
1.9.0.x or 2.0 -- being able to test and produce builds from branches
is going to be essential.  Maybe someone out there can cook up a
build-selector extension that will download and install a mar file
from a specific named build/branch, so that nightly users can switch
between these branches easily...
>  The danger is this is that we'd never be able to land large features
> which by their nature require more than 3 weeks of regression-fix
> time. Looking back on 1.9 with the promise of better
> distributed-branches tooling, do you think we could have landed cocoa
> widgets, cairo, places, threadmanager, or the reflow branch with less
> than 3 weeks of regressions? Or that we will be able to land XPCOMGC,
> (Tamarin) tracing, or compositor in 2.0 with less than 3 weeks of
>  regressions?

At least for cairo, back then, I don't think we could have.  Today?
It could have been a lot better: we have a huge testing infrastructure
that didn't exist before.  Just the reftests alone would've been
extremely helpful.
>  If we can, then we can make decisions about when to ship much later
> than we have... start doing work, and when the trunk seems suitably
> better than our current release, decide that we're going to do the
> Firefox 4 beta in a month, with another month of RCs for a total
> time-to-ship of 8 weeks.

I don't know whether this would be possible in practice; it may be for
a Gecko/platform release, but I think the front end work is always
going to lag behind platform work (because they need the platform work
in place to take advantage of the new functionality, if it's front-end
visible).

    - Vlad

--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo

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

Re: Thoughs on 1.9, 1.9.1, and 2

Mike Shaver
In reply to this post by Boris Zbarsky
On Fri, Mar 7, 2008 at 12:22 PM, Boris Zbarsky <[hidden email]> wrote:
>  I'm assuming we're up for arguments about the suitability of some of these
>  (worker threads jumps out at me) for a stable release?  I agree that some of
>  these others ought to be safe enough to add in a 1.9.0.x release, but see below.

Arguing about them seems inevitable, but building judgments of them
based on two-word descriptions is hopefully not inevitable. :)

>  If we do this sort of thing we'll need a much better testing (not just
>  automated, but user testing) and regression-fixing story than we've had with the
>  1.8.0 and 1.8.1 branches... but I'm assuming that's part of the plan anyway.

"Much better" lacks actionable detail, especially in concert with
"need" -- can you offer some specific states you think we would need
to be able to hit?

I think just having stuff beta in a tech-preview release sequence
would on its own increase the amount of test coverage dramatically,
and with isolated features the risk of one addition masking another's
badness gets pretty low.

>  One issue I worry about here is that some of these changes could in fact affect
>  web compat.  querySelector, ES4 things.  They shouldn't, but I won't bet there
>  is NO site out there that uses a function called querySelector that they attach
>  to nodes.

Yep, and I won't bet there are NO sites out there that weren't broken
by our jar: restrictions, etc.  A tech-preview beta channel gives us a
way to get some soaking on these things, but perfection can't be the
criterion.  There will be trade-offs here, and we'll have to make them
case-by-case.

>  See the issues we ran into with getElementsByClassName, some of which
>  are still pending evangelism action.  While we may be willing to take the
>  potential compat hit, it's worth checking on our various distributors (on Linux,
>  basically, since we do our own thing on Window/Mac).  Are they willing to go
>  with that approach?  Or are they going to start cherry-picking security fixes
>  but avoiding the feature ones?  That's a path we'd all like to avoid, I think.

That's a path I'd like to see the Linux distributors avoid, as well,
but I'm pretty sure they're interested in shipping Firefox, so I don't
think it's inevitable at all.  We should figure out what's right for
our product first, and then we can see how that fits in with
companies' other products.  (TBH, I have no idea what we're doing with
Linux builds these days; are we shipping the beta to people through
the channels we're expecting them to use for release?  That's another
thread!)

>  If we can swing it, I'd definitely prefer this approach to a 1.9.1 release,
>  because the things you list have vastly different development times.  For
>  example, querySelector and a lot of the remaining CSS3 selectors can probably be
>  wrapped up in 2 weeks.  I doubt <video> is that close to be being done, for example.

I don't know what the situation is with <video>, but I suspect it
takes 2 weeks just to build a basic test suite for it (not enough to
ship, possibly enough to get it in the Tech Preview train).

Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Stuart Parmenter-3
In reply to this post by Mike Shaver
On Mar 7, 9:43 am, Doug Turner <[hidden email]> wrote:
> i am not expecting to be on a mobile-specific branch.  Ideally, what
> we are planning for this year doesn't require large changes on to
> 1.9.  If we are wrong, we would switch over to Moz2.
>
imho, Mobile needs to follow the Mozilla 2 release.

stuart
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Mike Connor-4

On 7-Mar-08, at 2:18 PM, Stuart Parmenter wrote:

> On Mar 7, 9:43 am, Doug Turner <[hidden email]> wrote:
>> i am not expecting to be on a mobile-specific branch.  Ideally, what
>> we are planning for this year doesn't require large changes on to
>> 1.9.  If we are wrong, we would switch over to Moz2.
>>
> imho, Mobile needs to follow the Mozilla 2 release.

Care to explain why?

That's basically a strategic decision that its better to wait an extra  
year to ship something.  I don't think they have any intention at all  
of waiting that long, nor do I believe is it the right thing to do  
with the mobile product...

-- Mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Thoughs on 1.9, 1.9.1, and 2

Doug Turner-2
In reply to this post by Stuart Parmenter-3

On Mar 7, 2008, at 11:18 AM, Stuart Parmenter wrote:

> On Mar 7, 9:43 am, Doug Turner <[hidden email]> wrote:
>> i am not expecting to be on a mobile-specific branch.  Ideally, what
>> we are planning for this year doesn't require large changes on to
>> 1.9.  If we are wrong, we would switch over to Moz2.
>>
> imho, Mobile needs to follow the Mozilla 2 release.

why?

is mozilla 2 going to be ready for people to ship off of in 6 or 9  
months?
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
123