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
|

Re: Thoughs on 1.9, 1.9.1, and 2

Rob Sayre-2
On Mar 6, 8:50 pm, Vladimir Vukicevic <[hidden email]> wrote:
>
> 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 do not think this is the best time to set such a policy. Instead, I
suggest we get feedback on available new features as soon as possible,
without committing to any release for those features.

I wrote up a strawman for this some time ago (please don't get hung up
on the priorities, they're mostly illustrative):

  <http://wiki.mozilla.org/Technology_Preview>

This will get a pretty stable release with bleeding edge stuff into
users' hands quickly. This idea requires really strict testing
requirements, and I think that's OK. It will also avoid a debate about
which feature goes on which branch, and prevent schedule chicken. I
think the best strategy for Gecko versioning will be obvious once we
get a few of these out there. I find it very difficult to argue in
advance, and I think most of the arguments in this thread are based on
theoretical concerns (that could be correct, of course).

- Rob
_______________________________________________
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 Robert Kaiser
Robert Kaiser wrote:

> What about bonsai? mxr? tinderbox? all those work flawlessly with hg?
> Without them working, there's no chance of getting many of our people
> converted to this new world.

bonsai == hg.mozilla.org (hgweb)
MXR == mxr
tinderbox == tinderbox or buildbot

They all work. There are some minor flaws, but those have been noted (mainly
knowing about the history of changes as pushed to a particular branch) and
will be fixed.

--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

Benjamin Smedberg
In reply to this post by Robert Kaiser
Robert Kaiser wrote:

>> Without them working there's no chance of anyone getting onto that new
>> world, though I do think we have mozilla-central tinderbox coverage
>> now.  Do you really think that you're the only one who cares about
>> having tinderbox coverage of their work?  Really?  Really really?
>
> No, but I don't even see examples of how all those things do work, as
> not even Firefox has them yet, so I don't have any actual base to even
> think of how to solve it for SeaMonkey - if I am able to do that

What the hell are you talking about? We have buildbot, reporting to
tinderbox, with nightly builds right now. We even have scripts that pull
multiple repositories to do the build, mixing mozilla and tamarin mercurial
repositories with NSPR and NSS CVS repositories.

It's a working example; it's proof that it can be done. Now it's just a
matter of the SeaMonkey project finding time to do it.

> Exactly. Everything else is not present in current hg, and trust me,
> before we get near a SeaMonkey 2, our very very small team has no free
> cycles to set something up for ourselves.

SeaMonkey has been grandfathered into our build system, resulting in
unfortunately tight couplings. I've argued since the beginning of the 1.9
cycle that seamonkey (and thunderbird) are going to have to remove these
tight couplings to survive successfully as projects: in particular the
autocomplete binding stuff in xul.css, but also the general "build on top of
XULRunner/libxul" projects. I know that these projects are moving forward.
Until they are complete, seamonkey is in the unenviable position of being
stuck, coupled too tightly to our build system.

I do not think that SeaMonkey being understaffed should significantly
influence our decisions about how the Mozilla project and codebase moves
forward. If the project is so understaffed that it cannot even track Mozilla
development in 1.9, how will 1.9.1 become magically better?

--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

Robert Kaiser
In reply to this post by Benjamin Smedberg
Benjamin Smedberg wrote:

> Robert Kaiser wrote:
>
>> What about bonsai? mxr? tinderbox? all those work flawlessly with hg?
>> Without them working, there's no chance of getting many of our people
>> converted to this new world.
>
> bonsai == hg.mozilla.org (hgweb)
> MXR == mxr
> tinderbox == tinderbox or buildbot
>
> They all work. There are some minor flaws, but those have been noted
> (mainly knowing about the history of changes as pushed to a particular
> branch) and will be fixed.

 From what you say, everything sounds fine for moz2. We'll see for real
in fall or next year, whenever SeaMonkey will come around to actually
look into it and whoever will be doing the work then. It's good that we
have it here in the archives so that whoever will care about SeaMonkey
then will find those notices. I can't guarantee I'm around then. But
actually, who can?

For now, I'll keep this in the back of my mind, push it away from active
memory and tend to our immediate business.

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

Robert O'Callahan-2
In reply to this post by Robert O'Callahan-2
On Mar 9, 1:34 am, "Mike Shaver" <[hidden email]> wrote:

> On Sat, Mar 8, 2008 at 4:22 AM, Robert O'Callahan <[hidden email]> wrote:
> >  (By the same argument I think we
> >  should actually be more conservative about security fixes than we have
> >  been on the 1.8.1 branch, by not taking patches for some of the more
> >  obscure bugs.)
>
> I haven't heard you make that argument anywhere else; am I just
> missing the bugs you've commented in, or whatever thread you mentioned
> it on?  I don't want to add it to the scope of this thread, because I
> expect it to be pretty controversial, but I would like to discuss it
> for sure.  [My specific feelings about this position elided to avoid
> making it the subject of this thread.]

I haven't pushed the idea so I don't expect you to have heard it. But
it's been in my mind for a few weeks.
https://bugzilla.mozilla.org/show_bug.cgi?id=415447#c12

> >  2) At least some of our consumers (e.g. Thunderbird, most non-Firefox
> >  XUL apps, maybe mobile, probably Linux distros) will want to take
> >  security and stability fixes but the argument for having them take new
> >  platform features at the same time is weak. We should offer them
> >  something they can use.
>
> Do we poll these groups about what we take in 1.9.1, as well?  If
> Mobile doesn't want <video>, do we not take it?

No, that would be intolerable in the long term.

> I'm not starting from the assumption that those other groups would
> want to impose the cost of a third branch on us, necessarily, and I'm
> not presuming to know what "they can use".  I'm fine with asking them,
> but treating it as certain just helps fulfill that gloomy prophecy.

True. You and Blizzard should go ahead and ask them. If your report
sets my mind at ease, great.

> >  3) Even if we can pull it off, it will make things harder for
> >  developers. When 1.9 ships there will be two, maybe three Gecko
> >  feature sets that developers have to be aware of --- 1.9, 1.8.1, maybe
> >  1.8.0. If we add one feature in each 1.9.0.x release, we'll quickly
> >  have a much larger collection of feature sets that developers will see
> >  in the wild. "1.9.0.3 has downloadable fonts, 1.9.0.4 has video, now
> >  which one had the selector API?"
>
> Version checking is a sucker's game, and I don't think we should be
> hidebound by it.  We should be putting these in version-indistinct
> tech preview builds ahead of ship, which will help the key early
> sample code and library use be pushed towards object detection and
> content fallback.  (I agree that we shouldn't ship things to content
> that aren't safely detectable, which might mean that we have to change
> how we do our wholesale W3C IDL imports now, if we provide partial
> support for a given DOM standard.)

I'm not encouraging code-level version sniffing. However you detect
them, a plethora of feature sets creates complexity for developers:
additional code paths exercised, additional fallback required, and
additional thought and testing.

> >  There are a few features I'd be comfortable taking in 1.9.0.x --- very
> >  low level stuff that does not reach upward to the complexity of Web
> >  sites, is easy to test well, and is not directly exposed to
> >  developers. Examples of this would be cairo performance, JS
> >  performance, maybe SVG filter performance.
>
> It's harder to test the compatibility effects of a worthwhile JS
> performance win than to test the compatibility effects of
> querySelectorAll or <video>; SVG filter coverage is even worse, I bet.

Alright, take JS off the list. Since SVG filters are barely used,
regressing them is not so critical.

Rob
_______________________________________________
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 O'Callahan-2
In reply to this post by Mike Shaver
On Mar 9, 1:37 am, "Mike Shaver" <[hidden email]> wrote:
> Is it your belief that there is no platform feature so safe that we
> could take it on the branch?  Performance is a feature (just ask
> Apple; it's the only feature of their browser they advertise!) -- why
> would the arch-conservative downstream projects not reject a JS engine
> perf win, if they would reject a more isolated capability that can
> make web-hosted apps more compelling?

This is a game of tradeoffs. The world will not end if we take
platform features on branches. Regression risk is one downside, and I
have listed a couple of others, and stated my opinion that these
downsides suggest a 1.9.1 release makes more sense.

> I believe that we _increase_ regression and exposure risk by adding a
> third branch, thereby dividing effort (esp. manual-stochastic test
> coverage) and increasing the likelihood that a ported patch has some
> error not caught by our test suite.

I explicitly stated in my first message that I'm in favour of holding
the number of branches constant at 2.

Rob
_______________________________________________
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
etc.

I've been thinking about this some more.  It seems like we want to satisfy the
following constraints to get features out to web developers and make sure they
don't start to think of us as holding back the web while staying sane and
keeping users happy:

* Features shipping in a Gecko build
* Web developers realize that they are there
* Users are actually using that Gecko
* Avoid users feeling like they're on an upgrade treadmill
* Avoid having more than one security branch we maintain
* Avoid improvements breaking sites.

Shipping features in 1.9.0.x seems to satisfy the 1,3,4,5, since last I heard
uptake on the security releases was good, and users seem to be happy enough with
them.  It might satisfy 6, but sites might have to do more testing on a
continuous basis.  I'm not sure how well it would satisfy 2 unless we change the
way PR happens a good bit.  We would certainly get less PR-bang than shipping a
single release with multiple new web-developer goodies.

Shipping a 1.9.1, etc, with a quick (6-month or less, if it's to be useful, imo)
cycle would have issues with some combination of 3,4,5 depending on how we
handle the updates and how good user uptake is.  It's clear what the web
developer win would be here, but why should users upgrade?  We don't necessarily
want to force them because that would contribute to the treadmill perception.
We end up with two branches (1.9.0.x, 1.9.1.x) in this scenario.

There's also the question of what the Firefox version numbers look like here.
Perhaps something to do is to add web-facing features into Gecko 1.9.0.x, have
Firefox tracking that, then call one of the Firefox releases, say based on
1.9.0.5, Firefox 3.1 and market it to web developers a little.  Or something
like that.  There are issues here with the extension versioning, of course.

Maybe the problem of web developer awareness isn't as big as I think it is; I
think I end up with a pretty tilted view based on the articles and blogs I've
been seeing.  But it seems like people are slowly developing the perception that
we seriously lag Safari and Opera in standards support, and that's not a healthy
thing.  The worst part is that the perception can persist even if it's no longer
true if we never make it clear that it's no longer true....

Just trying to get this out of my head so I can actually sleep,
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

Axel Hecht
In reply to this post by Mike Shaver
L. David Baron wrote:

> On Friday 2008-03-07 09:32 -0500, 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.
>
> So it occurred to me with a full 40 minutes to spare before the
> localization freeze that if this is the plan, some of these features
> might need new strings.  I'm landing one string for bug 75375 in a
> few minutes.
>
> If anyone else can think of the same issue for other potential
> 1.9.0.x features, well, you have 22 minutes left.
>
> -David
>

I'm too ill to check, but I do hope that this didn't yield a plethora of
random string changes landing unapproved, just because it "might be
needed at some point for a new feature on 1.9.0.x".

Axel
_______________________________________________
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
In reply to this post by Vladimir Vukicevic-3
Ill or not, you should realize that Reed would have protected such a thing
from happening.

I tried - unsuccessfully - to stress that while we should definitely think
about these issues, nobody should stress themselves out too much thinking
that we're going to make final decisions without vetting plans at public
meetings and providing time for feedback. Also, I don't think we should get
all stop energy-ish around strings. If we need to mobilize out localizer
community around doing a string release, we can talk about the costs and
benefits of doing so. We certainly have the technology to distribute that
code to users on an active product branch, it's just a question of
investment.

Anyway, back to the conversation at hand, which has several interesting
offshoots and tangents that are illuminating (at least, to me)

cheers,
mike

(apologies for the top-post, this is written on my BlackBerry)

----- Original Message -----
From: [hidden email]
<[hidden email]>
To: [hidden email] <[hidden email]>
Sent: Sun Mar 09 23:43:31 2008
Subject: Re: Thoughs on 1.9, 1.9.1, and 2

L. David Baron wrote:

> On Friday 2008-03-07 09:32 -0500, 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.
>
> So it occurred to me with a full 40 minutes to spare before the
> localization freeze that if this is the plan, some of these features
> might need new strings.  I'm landing one string for bug 75375 in a
> few minutes.
>
> If anyone else can think of the same issue for other potential
> 1.9.0.x features, well, you have 22 minutes left.
>
> -David
>

I'm too ill to check, but I do hope that this didn't yield a plethora of
random string changes landing unapproved, just because it "might be
needed at some point for a new feature on 1.9.0.x".

Axel
_______________________________________________
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

schrep-2
In reply to this post by Stuart Parmenter-3
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.
>

Then Moz2 needs to release this year - because 1.9, as is, is good to go
for Mobile.  We can and will do a mobile release this year.

_______________________________________________
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

Shawn Wilsher
On Mar 10, 1:12 pm, schrep <[hidden email]> wrote:
> Then Moz2 needs to release this year - because 1.9, as is, is good to go
> for Mobile.  We can and will do a mobile release this year.
For those phoning in from home, when was this decided?  Past posts by
the mobile team seemed to indicate that they were unsure if 1.9 was
good or not yet.

Cheers,

Shawn Wilsher
_______________________________________________
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 schrep-2
On Mar 10, 10:12 am, schrep <[hidden email]> wrote:

> 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.
>
> Then Moz2 needs to release this year - because 1.9, as is, is good to go
> for Mobile.  We can and will do a mobile release this year.

Then ship 1.9 for mobile -- no need for 1.9.1 if it is "good to go."

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

fantasai
In reply to this post by Boris Zbarsky
Boris Zbarsky wrote:

> 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
> etc.
>
> I've been thinking about this some more.  It seems like we want to
> satisfy the following constraints to get features out to web developers
> and make sure they don't start to think of us as holding back the web
> while staying sane and keeping users happy:
>
> * Features shipping in a Gecko build
> * Web developers realize that they are there
> * Users are actually using that Gecko
> * Avoid users feeling like they're on an upgrade treadmill
> * Avoid having more than one security branch we maintain
> * Avoid improvements breaking sites.
>
> Shipping features in 1.9.0.x seems to satisfy the 1,3,4,5, since last I
> heard uptake on the security releases was good, and users seem to be
> happy enough with them.  It might satisfy 6, but sites might have to do
> more testing on a continuous basis.  I'm not sure how well it would
> satisfy 2 unless we change the way PR happens a good bit.  We would
> certainly get less PR-bang than shipping a single release with multiple
> new web-developer goodies.
>
> Shipping a 1.9.1, etc, with a quick (6-month or less, if it's to be
> useful, imo) cycle would have issues with some combination of 3,4,5
> depending on how we handle the updates and how good user uptake is.  
> It's clear what the web developer win would be here, but why should
> users upgrade?  We don't necessarily want to force them because that
> would contribute to the treadmill perception. We end up with two
> branches (1.9.0.x, 1.9.1.x) in this scenario.
>
> There's also the question of what the Firefox version numbers look like
> here. Perhaps something to do is to add web-facing features into Gecko
> 1.9.0.x, have Firefox tracking that, then call one of the Firefox
> releases, say based on 1.9.0.5, Firefox 3.1 and market it to web
> developers a little.  Or something like that.  There are issues here
> with the extension versioning, of course.

If it's adding new features and the user-facing release is called Firefox
3.1, why would we not change our Gecko branch number to 1.9.1 instead of
1.9.0.5?

I'm against adding features in an n.n.n.n+1 release. It's just silly: what
are we going to do next time we want to distinguish "minor Gecko feature
improvements" vs. "just security fixes", tack on *another* number? Draw
the branches however you want, name the Firefox release whatever the PR
guys tell you, but if it's including new features it should be a third-level
Gecko rev up imho, not a fourth-level one.

~fantasai
_______________________________________________
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

Neil-4
In reply to this post by Vladimir Vukicevic-3
Vladimir Vukicevic wrote:
> 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?
I may have overlooked it but I thought I read the whole thread yet I
didn't see an answer to this question.

My rationale is this: we are still converting SeaMonkey from xpfe to
libxul. This has uncovered a number or Core or Toolkit bugs or missing
features. It may uncover more that are as yet undiscovered. How are we
expected to deal with them in post-1.9 land?

Obviously this could depend on the impact of the bug so here are some
example bug numbers: 143065 (exposed by the switch to toolkit-based
preference system) 330101 363725 370109 379339 390771 395496 398874
399571 401388 406445 and 418213.

--
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: Thoughts on 1.9, 1.9.1, and 2

anaesthetica
On Apr 4, 7:10 am, Neil <[hidden email]> wrote:

> Vladimir Vukicevic wrote:
> > 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?
>
> I may have overlooked it but I thought I read the whole thread yet I
> didn't see an answer to this question.
>
> My rationale is this: we are still converting SeaMonkey from xpfe to
> libxul. This has uncovered a number or Core or Toolkit bugs or missing
> features. It may uncover more that are as yet undiscovered. How are we
> expected to deal with them in post-1.9 land?
>
> Obviously this could depend on the impact of the bug so here are some
> example bug numbers: 143065 (exposed by the switch to toolkit-based
> preference system) 330101 363725 370109 379339 390771 395496 398874
> 399571 401388 406445 and 418213.
>
> --
> Warning: May contain traces of nuts.

I think there's a good argument to have a 1.9.1 release before Moz 2.
Because of the major changes involved in Moz 2, it's unclear how
quickly that can be pushed out the door.  Nor is there a compelling
reason to rush Moz 2, since it's so important at a fundamental level
to Mozilla as a platform.  Better to do that one right than to do it
on an artificial timeline.

There was a minor flap not too long ago concerning whether Gecko was
basically just a Firefox oriented project, or whether it was a project
that was geared toward the entire ecosystem of products that use it
(SeaMonkey, Thunderbird, Camino, Songbird, Flock and so on).  It was
argued at that time that Gecko 1.9.0 should not be delayed in order to
include specific fixes for these other projects, and that releasing on
time for the Firefox 3.0 deadline was top priority.  Fixes for those
other application specific problems would, in general, wait.

A Gecko 1.9.1 release would presumably be geared toward the specific
fixes needed by all the other players in the Mozilla environment that
don't have the same priority as the flagship Firefox.  That's
understandable.  But eliminating a 1.9.1 release in order to focus on
Moz 2, which will land (at best) in 12 months, pushes off specific
fixes for the rest of the ecosystem even further.

It will be difficult to maintain four branches of Gecko code in
parallel--to that there is no argument.  However, for the health of
the Mozilla ecosystem and for Gecko as a viable platform, a 1.9.1
release would seem to have undeniable benefits.  In addition, above
posters have pointed out a number of pressing feature fixes for
Firefox itself that could do with a quicker release, and are not
inherently tied to the big changes in Moz 2.  This is a strong
argument for a 1.9.1 release, despite the additional overhead of
coordinating four Gecko branches at once.
_______________________________________________
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

Jonas Sicking-2
In reply to this post by Neil-4
Neil wrote:

> Vladimir Vukicevic wrote:
>> 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?
> I may have overlooked it but I thought I read the whole thread yet I
> didn't see an answer to this question.
>
> My rationale is this: we are still converting SeaMonkey from xpfe to
> libxul. This has uncovered a number or Core or Toolkit bugs or missing
> features. It may uncover more that are as yet undiscovered. How are we
> expected to deal with them in post-1.9 land?
>
> Obviously this could depend on the impact of the bug so here are some
> example bug numbers: 143065 (exposed by the switch to toolkit-based
> preference system) 330101 363725 370109 379339 390771 395496 398874
> 399571 401388 406445 and 418213.

This is definitely a hard problem. Ideally patches can be developed that
are safe enough to land post-1.9. The alternative is to try to find
resources that can get them fixed before 1.9 ships, which is getting to
be very short on time at this point.

It does seem like we're going to have another release not to far after
1.9 so this might be a good enough solution for now.

In general though I'm not really sure what possible solutions there can
be. We have to ship a given release at some point. I doubt that we will
ever be able to wait for fixes for all important bugs from all gecko users.

Do you have any suggestions?

/ Jonas
_______________________________________________
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

Greg K Nicholson-4
On Fri, 2008-04-04 at 17:21 -0700, Jonas Sicking wrote:
> In general though I'm not really sure what possible solutions there can
> be. We have to ship a given release at some point. I doubt that we will
> ever be able to wait for fixes for all important bugs from all gecko users.
>
> Do you have any suggestions?

Would it be feasible to have a Gecko 1.9.1 / Firefox 3.1 release
*replace* 1.9.0 / 3.0 ?

So it would essentially be a glorified 1.9.0.x / 3.0.x release with a
few new features added (but as little as possible *changed*).

I'm thinking particularly of things like Mardak's
awesomebar-with-added-awesomeness, that didn't land in time for 3.0.

If there were a general agreement that there were still enough things
missing from 1.9.1, there could be subsequent 1.9.x / 3.x releases.

_______________________________________________
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

Neil-4
Greg K Nicholson wrote:

> On Fri, 2008-04-04 at 17:21 -0700, Jonas Sicking wrote:
>    
>> In general though I'm not really sure what possible solutions there can be. We have to ship a given release at some point. I doubt that we will ever be able to wait for fixes for all important bugs from all gecko users.
>>
>> Do you have any suggestions?
>>      
> Would it be feasible to have a Gecko 1.9.1 / Firefox 3.1 release *replace* 1.9.0 / 3.0 ?
>
> So it would essentially be a glorified 1.9.0.x / 3.0.x release with a few new features added (but as little as possible *changed*).
>
> I'm thinking particularly of things like Mardak's awesomebar-with-added-awesomeness, that didn't land in time for 3.0.
>
> If there were a general agreement that there were still enough things missing from 1.9.1, there could be subsequent 1.9.x / 3.x releases.
>    
Sounds good to me.

Which RCS would 1.9.x use?

--
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: Thoughts on 1.9, 1.9.1, and 2

Benjamin Smedberg
In reply to this post by Greg K Nicholson-4
Greg K Nicholson wrote:

> Would it be feasible to have a Gecko 1.9.1 / Firefox 3.1 release
> *replace* 1.9.0 / 3.0 ?
>
> So it would essentially be a glorified 1.9.0.x / 3.0.x release with a
> few new features added (but as little as possible *changed*).

Then why wouldn't you just call it 1.9.0.x?

The key distinguishing factors between 1.9.0.x and 1.9.1.x are:

* do users get silent security updates of Firefox, or optional major update?
* do we break extensions?

If we can add features without changing APIs and with a reasonable hope of
not breaking the web, we should just do it on the 1.9.0.x line.

If we have to change APIs or break extensions, we're stuck in a situation of
supporting the stable line for 6 months after the 1.9.1 line comes out, for
security and stability updates.

--BDS
_______________________________________________
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

Jonas Sicking-2
Benjamin Smedberg wrote:

> Greg K Nicholson wrote:
>
>> Would it be feasible to have a Gecko 1.9.1 / Firefox 3.1 release
>> *replace* 1.9.0 / 3.0 ?
>>
>> So it would essentially be a glorified 1.9.0.x / 3.0.x release with a
>> few new features added (but as little as possible *changed*).
>
> Then why wouldn't you just call it 1.9.0.x?
>
> The key distinguishing factors between 1.9.0.x and 1.9.1.x are:
>
> * do users get silent security updates of Firefox, or optional major
> update?
> * do we break extensions?
>
> If we can add features without changing APIs and with a reasonable hope
> of not breaking the web, we should just do it on the 1.9.0.x line.

I don't really agree with this. A few reasons against doing this has
been brought up in this NG (I think in this thread even). One is that
1.9.0.x releases generally don't require l18n changes, which a new
feature generally would require. Another is that any new feature has a
big risk of breaking extensions in some way. For web features we have
examples like getElementsByClassName where just introducing a new
function broke a number of pages. As for chrome changes I imagine
anything with an id can affect overlays.

Any sort of breakage risks people getting turned off to the idea of
automatically applying security updates. Something that is really
important that it doesn't happen as it's one of our major tools to keep
the web safe.

There's also a risk that distributors will be more prone to cherry
picking the patches going into dot-release if we start putting new
features there. Again, this is something that we really want to avoid.

/ Jonas
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
123