Mozilla 1.6 Beta Freeze
Asa Dotzler
(PST). We'll be frozen through the release of 1.6 Beta and until the
branch for Mozilla 1.6 final which is scheduled to happen on Dec 12.
If you know of bugs which should block the release of Mozilla 1.6 Beta,
please nominate them using the blocking1.6b? bug flag. Once the freeze
is in effect, developers will need to get approval from
dri...@mozilla.org to land additional changes. To request approval
during the freeze, use the approval1.6b? patch flag.
--Asa
Asa Dotzler
The tree is frozen for Mozilla 1.6 Beta.
--Asa
Boris 'pi' Piwinger
> The tree is frozen for Mozilla 1.6 Beta.
Maybe it is a good idea to look at the blocker bugs:
http://bugzilla.mozilla.org/buglist.cgi?product=Browser&product=Calendar&product=JSS&product=MailNews&product=Mozilla+Localizations&product=NSPR&product=NSS&product=PSM&product=Rhino&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker
The people from de.comm.software.mozilla.misc have done a
great job and getting rid of more then 50 unconfirmed
blocker bugs (most are closed now). So the list becomes usable.
pi
Michael Lefevre
Having just glanced at the list, most of those shouldn't be "blocker"
severity. A blocker is supposed to be a bug which "Blocks development
and/or testing work" - bugs which have existed since 0.9.x days are
clearly not blocking development, let alone releases. For example, bug
74249 has been waiting for the reporter or someone to test it for nearly 2
years (if anyone reading has Mandrake and would like to check that out and
mark it WFM if it's not reproducible...)
We can almost certainly exclude the UNCOs and bugs that only affects ports
or non-standard builds (e.g. standalone Composer, MinGW, MSVC++ 7). Taking
those out and looking at only bugs filed since August 1st leaves just a
handful:
Bug 214321, which seems to be waiting for a testcase for some months, bug
217601 about the Eolas patent issue, where there's "no urgency to do
anything", and bug 215940 which is also waiting for some testing.
So I can't see anything on that list where I can imagine a possibility of
drivers making them block a release.
--
Michael
Boris 'pi' Piwinger
>> Maybe it is a good idea to look at the blocker bugs:
>> http://bugzilla.mozilla.org/buglist.cgi?product=Browser&product=Calendar&product=JSS&product=MailNews&product=Mozilla+Localizations&product=NSPR&product=NSS&product=PSM&product=Rhino&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_severity=blocker
>>
>> The people from de.comm.software.mozilla.misc have done a
>> great job and getting rid of more then 50 unconfirmed
>> blocker bugs (most are closed now). So the list becomes usable.
>
> Having just glanced at the list, most of those shouldn't be "blocker"
> severity.
Absolutely possible, but the list is already shrinking. Why
not by reducing the severity where applicable. Whatever is
left should be wort a look before the next release.
pi
Rick Stockton
> 74249 has been waiting for the reporter or someone to test it for nearly 2
> years (if anyone reading has Mandrake and would like to check that out and
> mark it WFM if it's not reproducible...)
1.5 "./moziller-installer" WFM on Mandrake 9.2. I posted a comment
but didn't change the status.
Simon Paquet
Thanks. I marked this bug (74249) WFM.
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)
Michael Lefevre
[snip]
>> Having just glanced at the list, most of those shouldn't be "blocker"
>> severity.
>
> Absolutely possible, but the list is already shrinking. Why
> not by reducing the severity where applicable. Whatever is
> left should be wort a look before the next release.
My point is that after taking out the various classes of bugs I mentioned
(which I did earlier with some more limited queries and then browsing the
remaining dozen bugs), I don't think there is anything left on the list to
look at for the release...
--
Michael
Boris 'pi' Piwinger
> My point is that after taking out the various classes of bugs I mentioned
> (which I did earlier with some more limited queries and then browsing the
> remaining dozen bugs), I don't think there is anything left on the list to
> look at for the release...
Absolutely fine with me. But similar to the discussion about
open flags for a release, I think that blocker bugs should
not exist at a release time. If someone from the drivers
group would just go over the list and do whatever is needed
to get rid of them, that would be great.
Again, several people already reduce the size of the list
dramatically (by about 20 bugs since yesterday!). So this is
doable.
pi
Michael Lefevre
> Michael Lefevre wrote:
>
>> My point is that after taking out the various classes of bugs I mentioned
>> (which I did earlier with some more limited queries and then browsing the
>> remaining dozen bugs), I don't think there is anything left on the list to
>> look at for the release...
>
> Absolutely fine with me. But similar to the discussion about
> open flags for a release, I think that blocker bugs should
> not exist at a release time. If someone from the drivers
> group would just go over the list and do whatever is needed
> to get rid of them, that would be great.
I'm not sure it needs to be someone from drivers to do that - drivers have
lots to do already, and some less important people(!) could do that stuff
(and if there are any likely candidates, then they can set the flag for
drivers to look at).
Also not possible to get rid of all the blockers - as I mentioned some of
them relate to ports or other unusual builds (MinGW, IRIX, standalone
Composer on MacOSX, to give examples from recent blockers on the list)...
Anyway, I think we're agreed it needs doing by someone, and it's now
getting done, so that's fine.
--
Michael
Boris Zbarsky
> Absolutely fine with me. But similar to the discussion about
> open flags for a release, I think that blocker bugs should
> not exist at a release time.
Is an unconfirmed bug with blocker severity a blocker bug?
-Boris
Boris 'pi' Piwinger
>> Absolutely fine with me. But similar to the discussion about
>> open flags for a release, I think that blocker bugs should
>> not exist at a release time. If someone from the drivers
>> group would just go over the list and do whatever is needed
>> to get rid of them, that would be great.
>
> I'm not sure it needs to be someone from drivers to do that
As I said, some people from the German newsgroups do it
already. You can really see the list shrinking. But there is
some rest.
> - drivers have
> lots to do already, and some less important people(!) could do that stuff
> (and if there are any likely candidates, then they can set the flag for
> drivers to look at).
The problem is that not everybody has the knowledge to
understand all those bugs. The "easy ones" are taken care of
already.
> Also not possible to get rid of all the blockers - as I mentioned some of
> them relate to ports or other unusual builds (MinGW, IRIX, standalone
> Composer on MacOSX, to give examples from recent blockers on the list)...
OK, but are that real blocker when releases are out for say
MacOSX?
pi
Boris 'pi' Piwinger
Well, it could well be, so it needs attention, but we got
those down by over 90% in the last few weeks.
pi
Michael Lefevre
>> - drivers have
>> lots to do already, and some less important people(!) could do that stuff
>> (and if there are any likely candidates, then they can set the flag for
>> drivers to look at).
>
> The problem is that not everybody has the knowledge to
> understand all those bugs. The "easy ones" are taken care of
> already.
Sure - but drivers aren't the only ones with the knowledge...
>> Also not possible to get rid of all the blockers - as I mentioned some of
>> them relate to ports or other unusual builds (MinGW, IRIX, standalone
>> Composer on MacOSX, to give examples from recent blockers on the list)...
>
> OK, but are that real blocker when releases are out for say
> MacOSX?
The bug is about standalone composer for Mac OS X, not Mozilla on Mac OSX.
They would be "real" blockers _if_ releases were made for those things on
those platforms. But they are not, and are not likely to be soon.
--
Michael
Andrew Schultz
An unconfirmed blocker is a real blocker about as often as a blue moon. People
who don't have enough experience to have canconfirm priveledge rarely know
enough to recognize when a bug is a blocker.
--
------------------------------------------------------------------
Andrew Schultz | The views expressed might
ajsc...@eos.ncsu.edu | not represent those of NCSU.
http://www4.ncsu.edu/~ajschult/ | They are however, correct.