Firefox / Gecko Development Meeting: Tue Dec 22 @ 11am PST
Mike Beltzner
General Agenda:
* development schedule for branch work
* blocker review for RC
* nomination review for RC
* holiday coverage
* quick overview and status updates, not expecting much here :)
Meeting Details:
* Agenda: https://wiki.mozilla.org/Platform/2009-12-22
* Tue, Dec 22, 11:00 am PST
* 650-903-0800 x92 Conf# 8605 (US/INTL)
* 1-800-707-2533 (pin 369) Conf# 8605 (US)
* join irc.mozilla.org #planning for back channel
cheers,
mike
Robert O'Callahan
Rob
Robert O'Callahan
https://wiki.mozilla.org/Talk:Firefox/Roadmap
I was told that bug 130078 was really important for Firefox 3.7. Does
this roadmap mean that it is no longer expected to be part of Firefox
3.7? Because backporting a core architectural change like that would
defeat the purpose of 1.9.2 being a "stable branch", IMHO. I feel the
same way about out-of-process-plugins, although that has less immediate
impact on me.
Rob
Mike Beltzner
> In the minutes I see a link to this:
> https://wiki.mozilla.org/Talk:Firefox/Roadmap
If you read the bits around that link, you'll note that it's being discussed as a proposal for discussion, and also by way of explaining why Benjamin is setting up a project branch. And now you're discussing it, so, success!
> I was told that bug 130078 was really important for Firefox 3.7. Does this roadmap mean that it is no longer expected to be part of Firefox 3.7? Because backporting a core architectural change like that would defeat the purpose of 1.9.2 being a "stable branch", IMHO. I feel the same way about out-of-process-plugins, although that has less immediate impact on me.
The bug in question is really important for JetPack to be able to provide the UI options that it needs in order to provide functionality to our Add-on authors. I don't think we profit from tying it to a specific release number, but rather to a set of capabilities we wish to deliver to our users (in this case, that set being Add-on developers) for some purpose.
If there is no way to achieve that goal on a stable branch due to the architectural changes required (and I'd challenge you to think hard about that) then it is not something that we can sensibly deliver in this proposed Q1 milestone, which would be specifically engineered to be delivered on the 1.9.2 branch. That doesn't mean that you shouldn't be prioritizing it as work on mozilla-central, or determining if there is a less invasive change that meets the needs of the JetPack team which can be delivered on the 1.9.2 branch.
(The communication around this is messy, and Shaver and I need to do better at organizing and mapping out the various technological pieces that are being proposed as well as how we hope to deliver them to users. It is my intention - and this was said at the meeting - to have this ready in the first weeks of 2010 to present at a development meeting.)
cheers,
mike
Boris Zbarsky
> If there is no way to achieve that goal on a stable branch due to the architectural changes required (and I'd challenge you to think hard about that) then it is not something that we can sensibly deliver in this proposed Q1 milestone, which would be specifically engineered to be delivered on the 1.9.2 branch. That doesn't mean that you shouldn't be prioritizing it as work on mozilla-central, or determining if there is a less invasive change that meets the needs of the JetPack team which can be delivered on the 1.9.2 branch.
Question on that. Do we have any performance goals for this milestone?
That is, should there be performance fixes of some sort being
backported to the 1.9.2 branch?
It seems like in some ways we might be better served by a 1.9.3 release
in Q2 than a 1.9.2-based release in Q1 at least from a
performance-comparison standpoint when being compared to other browsers.
Then again, I'm not sure what the jseng proposed schedule looks like,
and for better or worse that's what a lot of the performance comparisons
seem to be about...
-Boris
Robert O'Callahan
> better at organizing and mapping out the various technological pieces
> that are being proposed as well as how we hope to deliver them to
> users. It is my intention - and this was said at the meeting - to
> have this ready in the first weeks of 2010 to present at a
> development meeting.)
My big question is, why not just make more frequent releases off trunk?
Adding additional branches and backporting work sounds like extra work
that making releases off trunk would not incur, so you're accepting
slower overall development in exchange for sooner delivery of these
features (maybe; I'm not even convinced of that).
Rob
chris hofmann
atleast 250k-400k testers to examine any significant changes that we
might want to ship to users soon. We can either put just a few 'ship
early' changes into these rapid release betas, or we can put most/all
of the development work for the last 6 months into those betas. There
is more economy in trying to get more changes into these betas. Once
this larger group of changes has passed though a beta period like 3.6
has, why not just go ahead and ship them?
-chofmann
John J. Barton
Shortening the release schedule but avoiding backporting of features
also helps add-on developers. We lobby for important features any time
we can get them and we deal with the consequences. We lobby because we
believe the next release is very far off and uncertain.
This logic also applies to important features added late in the beta
cycle. Backporting and late changes disrupt Firebug's beta cycle, making
it hard for us to meet the Firefox release date. I would lobby against
these changes if the next release was 'soon' rather than 'gee we don't
know which year'.
What if 1) the features can only added during alpha phase, 2) the beta
version only accepted critical stability and security fixes plus fixes
to new features, and 3) the beta-one for "next" followed RC for the
current release? I think that would reduce churn and accelerate the cycle.
jjb
Mike Beltzner
> My big question is, why not just make more frequent releases off trunk? Adding additional branches and backporting work sounds like extra work that making releases off trunk would not incur, so you're accepting slower overall development in exchange for sooner delivery of these features (maybe; I'm not even convinced of that).
Being able to ship features more quickly is the goal, yes. When I discussed that possibility of branching a mozilla1.9.3 that contained only OOPP with Vlad, Benjamin and others, people brought up the fact that the trunk has already diverged so far that maintaining add-on and binary interface compatibility would be impossible.
In this specific case, as well, the code change is localized and shouldn't impact many people beyond the existing team already working on the Electrolysis project. I don't think it will slow down overall development. In fact, it will allow us to focus on stabilizing the existing changes on trunk for a delivery later in the year.
As I see it, the quickest way to get OOPP to users is to back-port the code to the soon to be released Firefox 3.6 / mozilla1.9.2 branch.
cheers,
mike
Robert O'Callahan
> We lobby because we believe the next release is very far off and uncertain.
Believing the next release is far-off is what makes it far-off.
Rob
Robert O'Callahan
> Being able to ship features more quickly is the goal, yes. When I
> discussed that possibility of branching a mozilla1.9.3 that contained
> only OOPP with Vlad, Benjamin and others, people brought up the fact
> that the trunk has already diverged so far that maintaining add-on
> and binary interface compatibility would be impossible.
OK, so that sounds like the real issue, then: you want the next Firefox
release to not rev add-on compatibility.
> In this specific case, as well, the code change is localized and
> shouldn't impact many people beyond the existing team already working
> on the Electrolysis project.
It's going to impact every user who uses plugins.
For developers, it's going to impact every platform developer who is
supposed to be working on features that go into the next Firefox.
> I don't think it will slow down overall development.
Extra branches and extra testing can't be free.
Shipping OOPP without revving compatibility actually does sound like a
reasonable goal. I suspect that the amount of testing and bugfixing
required to be confident all the crazy plugins out there work with OOPP
will take long, though. If we really want a quick release I think we
should consider just making Flash OOP for the first release.
Rob
John J. Barton
Yes, exactly my point. Consequently you can't shorten the release cycle
by technology alone.
jjb
Mike Shaver
> If we really want a quick release I think we should consider
> just making Flash OOP for the first release.
Yes, I think that would be a success case.
Mike
Mike Beltzner
> On Wed, Dec 30, 2009 at 5:10 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
>> If we really want a quick release I think we should consider
>> just making Flash OOP for the first release.
>
> Yes, I think that would be a success case.
It is also the way the goals for this quarter are expressed. I think we're all on the same page, here, now. As I mentioned before, I'm also trying to find better ways of communicating these strategy issues and answering questions about them. Suggestions welcome (but via private email to me, for now, please)
cheers,
mike
Tony Chung
> On 30/12/09 22:10, Robert O'Callahan wrote:
>> Shipping OOPP without revving compatibility actually does sound like a
>> reasonable goal. I suspect that the amount of testing and bugfixing
>> required to be confident all the crazy plugins out there work with OOPP
>> will take long, though. If we really want a quick release I think we
>> should consider just making Flash OOP for the first release.
>
> releases should be entirely possible.
>
> So we start with a big effort to QA and ship OOP Flash, and then for
> each point release, we identify from talkback the biggest remaining
> crash-causing plugin, test that OOP, make fixes and ship a whitelist
> with that plugin added. So the whitelist grows slowly but in the most
> effective way.
>
> Gerv
Agree with Gerv, i'd like to hear more on what should be prioritized for
testing if we plan to create another branch. Traditionally, QA runs
smoketests and focused bft testing on the builds before every point
release ship. Given we will have resource constraints to support
another branch, it would be really help us to start thinking of a
focused test pass (eg. heavy flash sites, and what else?) on which areas
would require the most focus for integration and regression testing.
Tony
Mike Beltzner
> Agree with Gerv, i'd like to hear more on what should be prioritized for testing if we plan to create another branch. Traditionally, QA runs smoketests and focused bft testing on the builds before every point release ship. Given we will have resource constraints to support another branch, it would be really help us to start thinking of a focused test pass (eg. heavy flash sites, and what else?) on which areas would require the most focus for integration and regression testing.
This discussion isn't really well suited to this thread, tbqh. We should start talking at tomorrow's development meeting, and if we formalize a plan (as proposed in the "Lorentz" thread in this newsgroup) then we can start building appropriate test plans, yes.
All test plans for all releases, IMO, should be tightly focused.
cheers,
mike
Philip Chee
Could you guys remember to give me (Flashblock) an early heads up in
case there is anything I need to change on my side to deal with OOP
flash? Thanks.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
Mike Shaver
> On Mon, 4 Jan 2010 10:16:26 -0500, Mike Shaver wrote:
>> On Wed, Dec 30, 2009 at 5:10 PM, Robert O'Callahan <rob...@ocallahan.org> wrote:
>>> If we really want a quick release I think we should consider
>>> just making Flash OOP for the first release.
>>
>> Yes, I think that would be a success case.
>
> Could you guys remember to give me (Flashblock) an early heads up in
> case there is anything I need to change on my side to deal with OOP
> flash? Thanks.
Here's an early heads-up, then! You can run trunk (mozilla-central)
nightlies with OOP plugins enabled, via the instructions posted to (I
believe) dev.platform and likely elsewhere. You are probably the best
person to tell if there are changes needed, but my understanding is
that there shouldn't be. Testing will tell the tale.
Mike
Jean-Marc Desperrier
> We lobby because we believe the next release is very far off and uncertain.
What do you call far off ?
I think the average user is ready to handle a real update ( not a very
minor, invisible one ) at most every 6 month.
If that's acceptable for you, then I think that would be the best plan
for Mozilla. Winter release, Summer release, with each time some
significant change, and a real extensive testing period before, but
*not* more frequent release than that !
In the current race for faster update, I'm afraid Mozilla might
underestimate the risk for update fatigue of the average user as well as
the need to polish each release. They are some users that never upgraded
to Firefox 3 because of bug 444600 (cookies erasure) which just got
fixed in trunk.
John J. Barton
> John J. Barton wrote:
>> We lobby because we believe the next release is very far off and
>> uncertain.
>
> What do you call far off ?
>
> I think the average user is ready to handle a real update ( not a very
> minor, invisible one ) at most every 6 month.
>
> If that's acceptable for you, then I think that would be the best plan
> for Mozilla. Winter release, Summer release, with each time some
> significant change, and a real extensive testing period before, but
> *not* more frequent release than that !
6 months is great; "at least 6 months" is not. Predictability is the
issue. Firefox is a platform with many dependents who need to plan their
work. If the rough schedule is agreed and if it is not so far out as to
be "forever" (ie more than a year), then the actual time is not critical.
> In the current race for faster update, I'm afraid Mozilla might
> underestimate the risk for update fatigue of the average user as well as
> the need to polish each release. They are some users that never upgraded
> to Firefox 3 because of bug 444600 (cookies erasure) which just got
> fixed in trunk.
Faster updates mean smaller updates. That makes updates less traumatic
for users and the reduces the scope of polish. Any large collection of
users will always generate push back on every change. We need to listen
carefully to their complaints, fix what we can, then move on. We should
avoid repeated changes to the same features of course.
jjb