2003-11-10 - Summary of mozilla.org staff meeting
Gervase Markham
-------------------------------------------------
Present: asa, leaf, mitchell, brendan, ben, dbaron, bart, scott, myk,
chofmann, dawn, gerv.
*Releases update*
- Not much said
*How much driving time for a release?*
- 1 week in beta of actual bug driving, make initial list 4 days before
- So 10 days of activity with 7 of daily bug triage
- Alpha is a couple of days shorter
- Final is someone looking at noms/approvs for a full cycle
- In total, more than 50% of the time is spent in this mode
- Is this too much or too little?
- We are trying to free up more of Asa's time to do community building
*New roadmap update*
- Asa has an operational update to make
*New website*
- Get together today and figure out if it's ready to go
- bart has commented the fonts are now too large
- The current size is 1 size larger than 95% of other websites
- drivers group for the website
- Need to document who these drivers are: mozilla.org/projects/website/
- Drivers need to review the list of outstanding website bugs regularly
- Make decisions on website formatting and structural changes
- Dawn to set up website-drivers alias
- Dawn to build the project homepage
- Need the raw materials for the new fonts and logos from David Shea
*@netscape.com addresses in important docs*
- Incremental changes
- rpotts to be removed
- See who knows the person
- Look at Bugzilla accounts for activity
- Gerv to deal
*bz's suggestion about flag policy at release time*
- This has been discussed on drivers
Gerv
Simon Paquet
>*bz's suggestion about flag policy at release time*
>
>- This has been discussed on drivers
Could someone please elaborate on this a little further as long as it isn't a
secret.
Ciao
Simon
--
In its default setup, Windows XP on the Internet amounts to a car
parked in a bad part of town, with the doors unlocked, the key in
the ignition and a Post-It note on the dashboard saying, "Please
don't steal this." (Washington Post)
Boris Zbarsky
> Could someone please elaborate on this a little further as long as it isn't a
> secret.
It's not a secret as far as I'm concerned (as in, I have no problems
with the mail I sent being reposted to this newsgroup).
-Boris
Gervase Markham
> It's not a secret as far as I'm concerned (as in, I have no problems
> with the mail I sent being reposted to this newsgroup).
Here it is, then, for your info:
bz said:
The following is a mail I sent this to drivers about 3 weeks ago, which
Gerv suggested I also send it to staff:
------------------------------------------------------------
It looks like 1.5 shipped while a number of "approval1.5?" patch flags
were still unresolved. Looking over the list, it looks like most of
these are in fact quite minus-worthy, especially at the late dates at
which they were set. A few of the bugs on the list, however, are
crashers, one a very common one.
Now I assume that the all the bugs involved were in fact looked at and
minused for 1.5. It would be good to set the flags to that effect
before making a release, though; otherwise we project the image of
simply not caring enough about the issues covered by the bugs to even
decide whether to take them for the release. That's not exactly a good
way to keep users happy, unfortunately... :(
------------------------------------------------------------
My constructive suggestion, now that I've gone through complaining about
what happened, is to simply make it a rule that outstanding "approval?"
and "blocking?" flags for a release should be resolved (and not
mass-resolved at that) before making the release. That guarantees that
someone has in fact looked over the bugs in question and made the call
that they are not worth holding the release for. This should hopefully
somewhat reduce cases of "oops, I guess we need a x.1 release."
-Boris
Michael Lefevre
> Boris Zbarsky wrote:
>
>> It's not a secret as far as I'm concerned (as in, I have no problems
>> with the mail I sent being reposted to this newsgroup).
>
> Here it is, then, for your info:
>
> My constructive suggestion, now that I've gone through complaining about
> what happened, is to simply make it a rule that outstanding "approval?"
> and "blocking?" flags for a release should be resolved (and not
> mass-resolved at that) before making the release.
On a related point, there are still 3 unfixed bugs with blocking1.5+,
which was set before the release.
Bug 159298 for example, was set to blocking1.5+ by chofmann and then the
patch was given approval1.5- by Asa. The others are bug 200511 and bug
217663 - in both of those cases, it looks like it was decided that they
weren't blockers, but that should have been (and probably should still be)
reflected in the flags.
So maybe the rule could be extended to say that there also shouldn't be
any unfixed bugs with blocking+ set.
--
Michael