June 27 Gecko 1.9 Planning/Status Meeting
Damon Sicore
PDT. Meeting agenda:
http://wiki.mozilla.org/Firefox3/StatusMeetings/
2007-06-26#Gecko_1.9_Meeting
Please add any agenda items as well as any Gecko 1.9-related progress
to this page/section.
Meeting Details
* Wednesday, June 27, 11:00 am PDT
* 650-903-0800 x91 Conf# 217 (US/INTL)
* 1-800-707-2533 (pin 369) Conf# 217 (US)
* join irc.mozilla.org #granparadiso for back channel
Cheers,
Damon
fantasai
A Rough Record of the Scheduling Discussion
-------------------------------------------
[Please don't take any of the names too seriously, I'm no good at recognizing voices.]
Shrep: Looking at next milestone. How are people feeling about Beta1? Scheduled freeze
in 2-3 weeks. Idea was full feature freeze.
?: From GFX perspective, Windows is basically done except for printing, Mac and Linux
still have issues.. hopefully knock out by then.
dbaron: I don't think we're ready. We've got a lot of bugs on the list, and we still
have lots of perf work and memory work.
Shrep: Next question is: at what point do we want wider testing coverage to find out
about configurations we don't know about?
Are we far enough in fixing regressions that that kind of data would be useful?
dbaron: probably
Shrep: Ground rules. I'm going to assert, tell me if I'm wrong. I'd like to ship FF3 as
high quality release and we are proud of, that is unequivocally better than FF2.
We care about fit and finish, performance, memory footprint.
Easy measure: at least as good as FF2.
Counter-balance: sooner is better. Lots of core improvements in platform, security
fixes, etc that we want to get out.
Shrep: Obvious from blockers that we need time to work on stuff. We said we'd do at least
2 betas. On Firefox side, month-long alpha cadences seem to be helpful. Does
1 month/6wks seem good to everyone?
??: I want to get to point were we stop working on new features.
???: I expected platform to be feature complete months ago.
Dscussion of features in progress (front end / back end). Contenteditable is in progress.
XS xml request. Jails thing (?)
dbaron: We've got some pretty scary stuff that's important to land, like ?'s pop-up patch.
He's holding that for after alpha. Jonas is planning to do some xbl stuff.
?: We should start making calls on this stuff, focus on perf and regressions.
??: We should only be working on blockers that are not new features.
???: Of those three, contenteditable is the one we've been getting a lot of requests for,
so I would push for that. But at some point we have to draw the line. The others
don't seem as critical to me.
Shrep: Proposal: do one more milestone after a6 as platform complete milestone: beta1.
Next question is, still a lot of FF work still under development. We might want
to do some more front-end work past beta1. That would imply more than 2 betas
for sure, so we have at least a beta cycle that is front-end frozen. This means
next beta is mainly for wider feedback, not feature complete, and not what to
expect for final release.
?: We have about a dozen things we could do that are small but would be perf increases.
Johnny: Does it make sense to call it a beta?
Shrep: Key distinction is how much feedback we want.
dbaron: Asking for feedback when it's bad means we'll get less feedback later.
roc: Feature I forgot to mention. Chris has a patch almost ready for review for
video?
Shrep: My short answer would be no, but we can discuss in bug. I'm trying to get
us to stop with the new code. We don't need more regressions.
roc: Chris doesn't have any other bugs assigned to him.
Shrep: Are we sure this won't introduce crashes, perf regressions, security issues, etc?
roc: Not likely to affect pages that don't use video.
Shrep: This isn't the last scheduled release in the next five years. We could do
a 1.9.1 to add things like that. I don't want people to think it's FF3 or
Mozilla 2. We should discuss that (1.9.1) with other people.
Axel: I wanted to find out if there's new feature development being done on offline.
(can't hear answer)
Shrep: So: contenteditable, xs httprequest, video, offline api work
(more mumbling)
Shrep: Objections to letting FF team run a little bit after beta1?
?: What do they expect to get from that?
Mike: New UI features, but not back-end stuff. E.g. places UI needs work after
back end is done. Other thing that won't make beta1 is front end for
nss/nspr EV certs. Nothing super-risky, mostly js/xul type stuff. There
will be new *features*, but it's all going to be front-end UI features
rather that has much back-end implications. That's why it seems safer
to take some of that later: it's more either works or doesn't, not works
on some sites and fails on others.
dbaron: fwiw I think it's a good idea. Also logical: platform has had much more
dev time, so we need much more time needed to fix regressions/perf.
Shrep: I propose the following. We have 7 features for platform, need to make go/no
go decisions on each of these.
contenteditable, xs httpreq, offline api, malware, video tag, ?, ?
Shrep: We'll call the next release beta for now, make final decision later, could
call it a7 if necessary. We will have extra milestone after beta2, call beta3
for now. Platform wraps up on beta1, FF on beta2.
Shrep: Additional milestones after that as needed, as few as necessary to hit quality
goals.
Shrep: Cycles' dev time should be min 2 weeks, max 6 weeks. Probably around 4 wks.
Need a week for respins.
?: Will move freeze from 17th to 18th, since we freeze on wednesdays. Freeze beta2
~ aug 22.
dbaron: We started requiring approval too early for FF2. We were basically approving
everything the first month or two.
dbaron: It doesn't have to be an approval process. We can say the policy is no features,
and if something looks like a feature we back it out.
?: At this point it should blockers only. Schedule has been out for a while, this
shouldn't be a surprise.
dbaron: The other thing about blockers only is that one of the things that happened at
Netscape when it was blockers only, lots of hygiene things stopped happening,
like stopped checking in tests.
mconnor: Modify it to say that tests are pretty much always ok. Blockers explicitly ok.
Anything that is not a blocker has to get approval from drivers. We don't
control everybody, and if they have a fix that is useful and isn't a blocker,
we should leave the door open for that. But to avoid overhead, blockers are
automatic approval.
?: We could start that, say, a week before freeze. Say after July 11th, anything other
than tests and blockers needs approval.
Shrep assigns himself some action items.
Shrep: betas will start automatic updates. First update from beta1 to beta2.
(This means more work for release team.)
~fantasai
Boris Zbarsky
> Shrep: So: contenteditable, xs httprequest, video, offline api work
I'd like to add a bit of remaining security architecture work to that list
(things like bug 370113). Not exactly blockers, probably, because it's been
wrong for so long. But definitely something I think we should be fixing...
Also, how does the "blockers only" approach, if implemented affect review
requests? Is doing reviews of things that are not blockers (e.g. the security
arch work stuff) still on the agenda?
-Boris
fantasai
I think that bug would fall under the
"Anything that is not a blocker has to get approval from drivers."
checkin policy, which takes effect after the 11th, and given the discussion
that lead to that, I think doing reviews for such patches would be ok.
But that's just my guess, I'm not a MozCorp manager.
~fantasai