Nabble - Mozilla - Seamonkey

Firefox / Gecko Development Meeting: Tue December 15 @ 11AM PST

2009-12-14T19:42:51Z

The next Firefox/Gecko Development Meeting will be Tuesday at 11am PST. See below for meeting time, location, and agenda.

General Agenda:
* Planning for the next release of 1.9.2
* discuss upcoming major changes landing on mozilla-central
* Status updates on feature development (both front-end and platform)
* Identifying areas of code risk for upcoming milestones
* Discussion of security review impacts, standards/spec compliance
work, internal and external dependencies

Meeting Details:
* Agenda: https://wiki.mozilla.org/Platform/2009-12-15
* Tue, Dec 15, 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

Sincerely,

Damon
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Making unexpected assertions turn the tree orange (for reftest/crashtest/jsreftest)

2009-12-14T14:56:21Z

[ Cross-posted to dev-planning and dev-tree-management. Please
follow up to dev-tree-management. ]

A while back, I added code to the reftest harness to report test
failures for unexpected assertions. I'm planning to turn this on on
mozilla-central in the next week or two.

This will significantly expand our test coverage for assertion
failures, which are currently tested for only on the very simple
leak test that the "L" builds do, and, I think, in C++ unit tests
and xpcshell tests. This will help us catch regressions that cause
new assertions, which are both annoying in themselves and often the
sign of underlying regressions that affect our users.

Turning this on will mean that:

(1) The reftest manifests will contain information about which
tests are known to cause assertions. These annotations can contain
ranges (when the number of assertions is random) and conditions,
such as:
asserts(3) == test ref # triggers 3 assertions
asserts(5-7) != test ref # triggers 5 to 7 assertions
asserts-if(MOZ_WIDGET_TOOLKIT=="gtk2",3) == test ref # 3 asserts on GTK
asserts-if(MOZ_WIDGET_TOOLKIT=="windows",0-1) == test ref # sometimes asserts on Windows

(2) When there are more assertions than expected, the harness will
report an unexpected failure (and continue running the rest of the
tests).

(3) When there are fewer assertions than expected, the harness will
report an unexpected pass (and continue running the rest of the
tests).

This affects the reftest, crashtest, and jsreftest test runs in
debug builds only. This means that the only tinderbox builds that
will be affected are the "debug test everythingelse" or "Ed" builds.

It is likely that my initial round of manifest annotation will be
incomplete: i.e., it will not cover some of the less frequent
random assertions. These can be added to the manifests when they
are observed.

https://bugzilla.mozilla.org/show_bug.cgi?id=472557 has more
details. For more on the manifest format, see
http://mxr.mozilla.org/mozilla-central/source/layout/tools/reftest/README.txt

I'll post again when this is actually enabled (including a pointer
to which changeset would need to be backed out if it causes too much
trouble).

-David

--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

FRIDAY FRIDAY FRIDAY: Destroy Firefox 3.6 Before its Final Release!

2009-12-14T14:38:18Z

This is it everyone. We're coming to the end of Firefox 3.6 and the quality team is trying to pull out all the stops in making the quality of the browser as good as it possible can be. The only way to do that is through our community and to get us all together, we're going to be holding a testday this Friday, December 12th, from 7AM to 5PM PST to try our best to thoroughly destroy the latest Firefox 3.6 Beta build!

To learn more about this, take a look at:
http://quality.mozilla.org/events/2009/dec/18/testday-destroy-firefox-36-its-final-release

Otherwise, join us on #testday at irc.mozilla.org this Friday. Bring your construction hats and favorite destruction tools!

Thanks and We'll See You There,
aakashd
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Multi-process plugins landing Monday

2009-12-14T13:57:20Z

On 12/13/09 10:05 PM, Benjamin Smedberg wrote:
> I intend to close mozilla-central and merge Electrolysis plugins
> tomorrow morning.

Status update:

* The red on x86-64 was caused by it running GCC 4.2, which has known bugs
relating to symbol visibility. I have fixed this by changing the x86-64
mozconfig, see bug 534696

* The Tp4 hang on mac occurred, and it turns out that it was very likely
caused by us not loading plugins at all on mac (except for the testplugin).
This was fixed by bug 534682. Thanks for the quick work from Chris for the
report and Josh for finding the bug! I'll file a bug to test the condition
that we broke.

* The orange in jsreftest is a test that was supposed to succeed, but was
failing on Windows for reasons unknown. We've switched it to be a passing
test. See http://hg.mozilla.org/mozilla-central/rev/9f7c1fa9b2de This
wasn't identified earlier because Electrolysis was not running the jsreftest
suite, which is also now fixed.

* A variety of fixes landed for SeaMonkey builds, see the log for details

* One fix for SeaMonkey remains to land (see bug 534701)

* I have not noticed any adverse performance effects, but we've only had 1
or 2 Talos runs since the landing. I'll be monitoring this tonight and
tomorrow, but I don't think that needs to block reopening the tree.

* Assuming everything sticks, I'll write up a blog post tomorrow explaining
how to actually enable multi-process plugins, and the next steps toward
actually turning it on by default.

Followup to mozilla.dev.tree-management please.

--BDS
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Top Crash Kill Kill Kill Meeting: Monday, Dec 14 @ 3PM PDT

2009-12-14T12:38:25Z

There will be a meeting, information below, to discuss the killing of crashes, status on current tracked crashes, and tools to help track and find crashes.

General Agenda:
* Status update on crashes in latest 3.6 beta
* Identify new crashes and make sure we have resources on top of them.

Meeting Details:
* Agenda & Notes: https://wiki.mozilla.org/CrashKill/2009-12-14
* Monday, Dec 14, 3:00 PM PDT
* 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

Sincerely,

Damon
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: RESOLVED: ITTOOKUSTOOLONG

2009-12-14T10:02:08Z

On 10/12/09 16:38, John J Barton wrote:
> Sorry if this is not quite the right venue, I forgot where the
> mozilla-bugzilla issues are discussed.

mozilla.tools would be the place, although it's quite new.

> This is yet another let's-insult-the-user category and anyway does not
> fit the "bug report filed against FF 2" category. Ok the bug was not
> important enough for someone to act on, fine, just say so.

A fair point.

RESOLVED: SORRYWESUCK? :-)

Gerv

_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: RESOLVED: ITTOOKUSTOOLONG

2009-12-14T10:01:06Z

On 11/12/09 20:47, John J. Barton wrote:
> That choice does not seem to be on the list of possible resolutions.

That resolution was designed to only be set programmatically, on bugs
which meet certain criteria. So it doesn't show up in the standard list.

Gerv
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Threading don't work for one mail address

2009-12-14T06:36:37Z

Arne:
>Hartmut Figge wrote:
>> Arne:

>>> Hope that is the right place?
>>
>> Perhaps. I don't know anything about Windows. But if the prefs.js is in
>> this directory, then it should be the right place.
>
>Yep, the prefs.js is there.

Fine. You could check with 'about:config' if the setting was successful.

But another point. Crossposting without Followup-To is evil. And in this
special case .planning should not have been included. The right group
for your question is .support.seamonkey.

f'2 mozilla.support.seamonkey

Hartmut
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Threading don't work for one mail address

2009-12-14T06:25:05Z

Hartmut Figge wrote:

Yep, the prefs.js is there.

> Unless of course you use multiple profiles. ;)

Nope, one is enough. I'm creating a test profile when/if I need to
solve any problems where a clean profile is useful. ;)

> I could give a link to the German FAQ for profiles and user.js, but i
> doubt that this would make you happy. *g*

Well, I don't know much German, but I manage to understand some. Some
years ago I was even enable to talk with a Russian doctor when I need
some medical care when visiting Russia. The doctor did not talk or
understand English at all, but German fairly good. :D

--
/Arne
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Threading don't work for one mail address

2009-12-14T05:31:04Z

Please remove mozilla.dev.planning from the follow-up list. This is not appropriate discussion for this newsgroup.

cheers,
mike

On 2009-12-14, at 8:07 AM, Hartmut Figge wrote:

> Arne:
>
>> I could not find any existing user.js file in my Vista, so I created
>> one to
>> C:\Users\Arne\AppData\Roaming\Mozilla\SeaMonkey\Profiles\ck0att16.default\
>
>> Hope that is the right place?
>
> Perhaps. I don't know anything about Windows. But if the prefs.js is in
> this directory, then it should be the right place.
>
> Unless of course you use multiple profiles. ;)
>
> I could give a link to the German FAQ for profiles and user.js, but i
> doubt that this would make you happy. *g*
>
> Hartmut
> _______________________________________________
> dev-planning mailing list
> dev-planning@...
> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Threading don't work for one mail address

2009-12-14T05:07:31Z

Arne:

>I could not find any existing user.js file in my Vista, so I created
>one to
>C:\Users\Arne\AppData\Roaming\Mozilla\SeaMonkey\Profiles\ck0att16.default\

>Hope that is the right place?

Perhaps. I don't know anything about Windows. But if the prefs.js is in
this directory, then it should be the right place.

Unless of course you use multiple profiles. ;)

I could give a link to the German FAQ for profiles and user.js, but i
doubt that this would make you happy. *g*

Hartmut
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Threading don't work for one mail address

2009-12-14T04:55:09Z

Hartmut Figge wrote:

> Arne:
>> Hartmut Figge wrote:
>
>>> ----- user.js -----
>>> user_pref("mailnews.localizedRe", "SV,Sv");
>>> ---------------
>>
>> Thanks, but what does that do? I don't like my SM to use SV or Sv. Re:
>> is just fine and should be universally used. ;)
>
> That replaces occurrences of 'SV' or 'Sv' with 'Re'. I am using the
> similar Pref 'user_pref("mailnews.localizedRe", "AW,Aw");' because
> especially OE tends to use AW or Aw - abbreviation of Antwort - here in
> Germany.
>
> I don't like Aw: Re: Aw: Aw: Re: :)

Aha, thanks!

I could not find any existing user.js file in my Vista, so I created
one to
C:\Users\Arne\AppData\Roaming\Mozilla\SeaMonkey\Profiles\ck0att16.default\

Hope that is the right place? As I believe the profiles for SM 1.1.18
is on C:\Users\Arne\AppData\Roaming\Mozilla\Profiles\

--
/Arne
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Threading don't work for one mail address

2009-12-14T04:22:06Z

Arne:
>Hartmut Figge wrote:

>> ----- user.js -----
>> user_pref("mailnews.localizedRe", "SV,Sv");
>> ---------------
>
>Thanks, but what does that do? I don't like my SM to use SV or Sv. Re:
>is just fine and should be universally used. ;)

That replaces occurrences of 'SV' or 'Sv' with 'Re'. I am using the
similar Pref 'user_pref("mailnews.localizedRe", "AW,Aw");' because
especially OE tends to use AW or Aw - abbreviation of Antwort - here in
Germany.

I don't like Aw: Re: Aw: Aw: Re: :)

Hartmut
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Threading don't work for one mail address

2009-12-14T04:12:08Z

Hartmut Figge wrote:

> Arne:
>
>> As I said, I can see the point in threading By the "References" line
>> in the header. The backside of threading by subject is that when I
>> receive mails sent from mail programs (i.e. OE) "translated" to my
>> native language (Swedish) they may not thread correctly, since the
>> "Re:" is changed to "SV:". So the subject line can have a lot of "Re:
>> SV: Re: SV: after posting back and forth several times. ;)
>
> ----- user.js -----
> user_pref("mailnews.localizedRe", "SV,Sv");
> ---------------

Thanks, but what does that do? I don't like my SM to use SV or Sv. Re:
is just fine and should be universally used. ;)

--
/Arne
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Multi-process plugins landing Monday

2009-12-14T02:49:29Z

On 14 Dec 2009, at 03:05, Benjamin Smedberg wrote:

> I intend to close mozilla-central and merge Electrolysis plugins tomorrow morning.

Yay! :)

>
> There are two "unknowns" that may cause this merge to be backed out:
>
> * Performance regression on Windows. The Electrolysis tree has a performance regression on Windows when compared with mozilla-central. We have been unable to reproduce this on local machines or Tryserver, so we believe it's a measurement fluke of some sort.
>
> * Tp4 hanging on mac. Tp4 is hanging pretty reguarly on mac-E10s. Olli and I have examined this and can reproduce, but it's equally reproducable on mozilla-central, so we believe again that it's a measurement fluke of some sort.

I have just landed bholley's patch for bug 516334, which is a possible cause of Tp4 hang. You might like to try that patch in your E10s tree as well, and see if it helps; in my local testing, it reliably fixes a frequent-but-erratic Mac Tp4 hanging issue.

JK

>
> Expect the tree to stay closed for 4-6 hours as Talos and unit tests run. Please let me know if that is a problem.
>
> --BDS
> _______________________________________________
> dev-planning mailing list
> dev-planning@...
> https://lists.mozilla.org/listinfo/dev-planning

_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Threading don't work for one mail address

2009-12-14T02:48:26Z

Arne:

>As I said, I can see the point in threading By the "References" line
>in the header. The backside of threading by subject is that when I
>receive mails sent from mail programs (i.e. OE) "translated" to my
>native language (Swedish) they may not thread correctly, since the
>"Re:" is changed to "SV:". So the subject line can have a lot of "Re:
>SV: Re: SV: after posting back and forth several times. ;)

----- user.js -----
user_pref("mailnews.localizedRe", "SV,Sv");
---------------

Hartmut
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Threading don't work for one mail address

2009-12-14T02:39:22Z

Neil wrote:

> Arne wrote:
>
>> The mails with same subject that are not reply's has of course not any
>> reference.
>
> If you want to thread mails by subject you need to turn off the
> mail.strict_threading preference. If the replies don't begin with Re:
> then you will also need to turn on the mail.thread_without_re
> preference. After using about:config to change these preferences you
> will need to restart; then you can rebuild the summary file to rethread
> the messages.
>

Thank you Neil, now it works as I intended. Of course, that change in
about:config is "global" for all mail accounts. Wish it could be set
per account.

As I said, I can see the point in threading By the "References" line
in the header. The backside of threading by subject is that when I
receive mails sent from mail programs (i.e. OE) "translated" to my
native language (Swedish) they may not thread correctly, since the
"Re:" is changed to "SV:". So the subject line can have a lot of "Re:
SV: Re: SV: after posting back and forth several times. ;)

But at least now I'll see what option is more inconvenient in a long
view, and can change it back if I want to.

--
/Arne
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Threading don't work for one mail address

2009-12-14T01:35:09Z

Arne wrote:

> The mails with same subject that are not reply's has of course not any
> reference.

If you want to thread mails by subject you need to turn off the
mail.strict_threading preference. If the replies don't begin with Re:
then you will also need to turn on the mail.thread_without_re
preference. After using about:config to change these preferences you
will need to restart; then you can rebuild the summary file to rethread
the messages.

--
Warning: May contain traces of nuts.
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Weekly Status Meeting - December 14, 2009

2009-12-13T23:52:32Z

Meeting Details:
* 11:00am Pacific Standard Time (19:00 UTC)
* Mozilla HQ, Ten Forward area
* +1 650 903 0800 x92 Conf# 8600 (US/International)
* +1 416 848 3114 x92 Conf# 8600 (Canada)
* +1 800 707 2533 (pin 369) Conf# 8600 (US Toll Free)
* sip:weeklystatus@... from generic SIP clients
* http://air.mozilla.com/ to watch and listen
* join irc.mozilla.org #staffmeeting for backchannel

Add your agenda items/status here prior to the meeting:
https://wiki.mozilla.org/WeeklyUpdates/2009-12-14

--Tim
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Threading don't work for one mail address

2009-12-13T22:17:58Z

Hi,
I have several email accounts and to one of them I am receiving an
email notice from a web forum when new posts are posted on threads I
have subscribed to. The account is not used for any other purpose.

On SM 1.1.18 the emails concerning the same forum thread was always
threaded in my inbox for the mail account. Now on SM 2.0 the threading
don't work on that specific email account, as it does for all other
accounts.

When testing to send "ordinary" email to the "forum mail account" and
replying from and to it, the mails are threaded. So I guess something
is changed in the way SM recognize the emails even if they have the
same subject?

I can see in the mail header for the reply that it has a "References:"
line, ref to the mail it reply's to. The mails with same subject that
are not reply's has of course not any reference.

I can see the point in not threading mails that are not connected even
if the subject is the same. But in this case with the mails from the
web forum, I would appreciate if I could have an option to get them
threaded by subject. Any chance to do that now or in the future, even
if I had to do that manually for selected mails?

Cross posted to mozilla.dev.apps.seamonkey and mozilla.dev.planning,
feel free to set follow up to the appropriate group.

--
/Arne
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Multi-process plugins landing Monday

2009-12-13T19:05:14Z

I intend to close mozilla-central and merge Electrolysis plugins tomorrow
morning.

There are two "unknowns" that may cause this merge to be backed out:

* Performance regression on Windows. The Electrolysis tree has a performance
regression on Windows when compared with mozilla-central. We have been
unable to reproduce this on local machines or Tryserver, so we believe it's
a measurement fluke of some sort.

* Tp4 hanging on mac. Tp4 is hanging pretty reguarly on mac-E10s. Olli and I
have examined this and can reproduce, but it's equally reproducable on
mozilla-central, so we believe again that it's a measurement fluke of some sort.

Expect the tree to stay closed for 4-6 hours as Talos and unit tests run.
Please let me know if that is a problem.

--BDS
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

SeaMonkey Status Meeting - Tue, December 15

2009-12-13T18:45:31Z

Agenda: https://wiki.mozilla.org/SeaMonkey:StatusMeetings:2009-12-15

* December 15, 13:00 UTC, 8am Eastern, 1pm UK, 2pm Central Europe
* Other timezones:
http://www.timeanddate.com/worldclock/fixedtime.html?day=15&month=12&year=2009&hour=13&min=0&sec=0&p1=0
* IRC channel #seamonkey - irc://irc.mozilla.org/seamonkey

Hi everybody,

We're doing another instance of our biweekly SeaMonkey Status meetings
on IRC.

Please add agenda items we should discuss, we're trying to get a good
view there where the SeaMonkey project is right now, what's the progress
compared to last time and where we are headed.

Main agenda items:
- SeaMonkey 2.0 Feedback
- 2.0.1, 2.0.2 Planning
- Feature List, Planning for 2.1
- Roundtable

Thanks,

Robert Kaiser
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Thunderbird 3 is now available for download

2009-12-13T13:13:04Z

2009.12.12 22:40, Magnus Melin rašė:

> On 09.12.2009 10:03, Rimas Kudelis wrote:
>>> Thanks, Larry - very interesting. I've been set for Western (ISO 8859-1)
>>> "forever", and never noticed this before. If I set View to UTF-8, Mark's
>>> message looks OK. (Autodetect does NOT help.) I'm not about to change
>>> encoding settings depending on who's sending.
>>>
>>> BTW, I agree I sent in 1252, although I'm NOT set to do that. It appears
>>> that replying to UTF-8 causes this.
>>>
>>> I'm still not sure what's going on, but based on this and a number of
>>> negative comments here (yes, I know negatives outweigh positives in
>>> newsgroups), I think I'll stay put with 2.0.0.23 for the time being.
>>
>>
>> I guess the problem is that you've set the option where the default
>> character set you've set OVERRIDES whatever is in the header of a
>> message. Make sure to uncheck that checkbox, you'll find it in the
>> properties dialog for this newsgroup and/or in global preferences dialog.
>
> The UI for the global pref to override was removed for tb3, as it's a
> sure way to shoot yourself in the foot - the pref is
> mailnews.force_charset_override.

I know that, Magnus.

It was removed from the global settings, but it remains in each
newsgoup/folder settings dialog. That's what I referred to. Though
surely, the global option is a big suspect too.

Rimas
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Thunderbird 3 is now available for download

2009-12-12T12:40:11Z

On 09.12.2009 10:03, Rimas Kudelis wrote:

>> Thanks, Larry - very interesting. I've been set for Western (ISO 8859-1)
>> "forever", and never noticed this before. If I set View to UTF-8, Mark's
>> message looks OK. (Autodetect does NOT help.) I'm not about to change
>> encoding settings depending on who's sending.
>>
>> BTW, I agree I sent in 1252, although I'm NOT set to do that. It appears
>> that replying to UTF-8 causes this.
>>
>> I'm still not sure what's going on, but based on this and a number of
>> negative comments here (yes, I know negatives outweigh positives in
>> newsgroups), I think I'll stay put with 2.0.0.23 for the time being.
>
>
> I guess the problem is that you've set the option where the default
> character set you've set OVERRIDES whatever is in the header of a
> message. Make sure to uncheck that checkbox, you'll find it in the
> properties dialog for this newsgroup and/or in global preferences dialog.

The UI for the global pref to override was removed for tb3, as it's a sure way
to shoot yourself in the foot - the pref is mailnews.force_charset_override.

-Magnus

_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: RESOLVED: ITTOOKUSTOOLONG

2009-12-11T20:47:49Z

Martijn wrote:
> I guess this is similar to the RESOLVED: EXPIRED thing, which already
> exists for a while?

That choice does not seem to be on the list of possible resolutions.
jjb

> See here for one of the discussions that took place about that one:
> http://weblogs.mozillazine.org/gerv/archives/006570.html

>
> Regards,
> Martijn
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: RESOLVED: ITTOOKUSTOOLONG

2009-12-11T09:45:09Z

I guess this is similar to the RESOLVED: EXPIRED thing, which already
exists for a while?
See here for one of the discussions that took place about that one:
http://weblogs.mozillazine.org/gerv/archives/006570.html

Regards,
Martijn

On Fri, Dec 11, 2009 at 1:38 AM, John J Barton
<johnjbarton@...> wrote:

> Sorry if this is not quite the right venue, I forgot where the
> mozilla-bugzilla issues are discussed.
>
> The RESOLVED category is missing a very important case: a category for bug
> reports that were not evaluated in a timely manner. Apparently these get
> dumped into RESOLVED: INCOMPLETE, which described:
>
> The bug is vaguely described with little to no steps to reproduce.
>
> http://quality.mozilla.org/bugs-life-walkthrough#resolved
>
> This is yet another let's-insult-the-user category and anyway does not fit
> the "bug report filed against FF 2" category. Ok the bug was not important
> enough for someone to act on, fine, just say so.
>
> jjb
> _______________________________________________
> dev-planning mailing list
> dev-planning@...
> https://lists.mozilla.org/listinfo/dev-planning
>

--
Martijn Wargers - Help Mozilla!
http://quality.mozilla.org/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

RESOLVED: ITTOOKUSTOOLONG

2009-12-10T16:38:03Z

Sorry if this is not quite the right venue, I forgot where the
mozilla-bugzilla issues are discussed.

The RESOLVED category is missing a very important case: a category for
bug reports that were not evaluated in a timely manner. Apparently these
get dumped into RESOLVED: INCOMPLETE, which described:

The bug is vaguely described with little to no steps to reproduce.

http://quality.mozilla.org/bugs-life-walkthrough#resolved

This is yet another let's-insult-the-user category and anyway does not
fit the "bug report filed against FF 2" category. Ok the bug was not
important enough for someone to act on, fine, just say so.

jjb
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Mozilla Scheduled Downtime – 12/10/2009, 6pm – 12pm PST (0200 – 0800 12/11/2009 UTC)

2009-12-10T15:13:11Z

We will have a scheduled maintenance window tonight from 6:00pm to
12:00pm PST. The following changes will take place:

* 6:00pm PST (0200 UTC) Kernel upgrades. We’ll be doing kernel
security updates on various machines affecting the following services
for approximately 10 minutes each:

• *ALL* sm-* (development) servers.
• All IT-administered build services, including build.mozilla.org,
try server, cruncher, AUS staging, and the pageload/graph servers
• All VPNs and jumphosts in the offices and colos (except Beijing)
• All office and colo DNS and DHCP servers (except Beijing)
• All Web-dev and app staging servers
• support.mozilla.com (chat services and knowledge base)
• All version control services and related utility services (CVS, CVS-
mirror, Hg, SVN, Bonsai, HgWeb, ViewVC, Tinderbox, MXR)
• ftp.mozilla.org
• stage.mozilla.org
• people.mozilla.com
• intranet.mozilla.org
• quality.mozilla.org
• litmus.mozilla.org
• irc.mozilla.org (multiple servers, will fail over via DNS to keep
it up)
• addons.mozilla.org
• download.mozilla.org
• videos.mozilla.org
• nagios.mozilla.org
• bugzilla.mozilla.org
• developer.mozilla.org
• spreadfirefox.com
• Internet-facing mail relays, list servers, and outbound mail (mail
will be queued)
• All public and private wikis and blogs administered by Mozilla

Some services may have more than one outage as various back-end
components each get their upgrades (for example, a web application
will go down once when the web servers are upgraded and again when its
database server is upgraded).

* 7:00pm PST (0300 UTC) LDAP upgrade. We’ll be upgrading OpenLDAP
tonight. Our LDAP infrastructure is redundant and there shouldn’t be
any downtime noticed. Duration 30 minutes.

* 9:00pm PST (0500 UTC) Zeus TM configuration changes. We’ll be
turning some SSL cache settings on the production Zeus cluster (bug
533809). No downtime is expected.
Please let me know if you have any reason why we should not proceed
with this planned maintenance. As always, we aim to keep downtime to
as little as possible, but unexpected complications can arise causing
longer downtime periods than expected. All systems should be
operational by the end of the maintenance window.

Feel free to comment directly if you see issues past the planned
downtime.
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Removing restriction on mozilla-central

2009-12-10T09:36:36Z

On Wed, Dec 9, 2009 at 7:10 PM, Dao <dao@...> wrote:

> Any update on this?
>
>
We're open for sheriff-approved checkins right now. I've volunteered to
sheriff for the day, so find me in #developers to get permission to land.
I'm going to try to keep the flow of checkins slow to avoid breaking things.

-Ted
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

mozilla-central is open again

2009-12-10T09:32:09Z

Hi everyone,

We're down to the last few bugs for mozilla1.9.2/Firefox 3.6, and they're localized enough that we've decided to re-open the mozilla-central tree for checkins. Since we expect that there might be a backlog, Ted's (been) volunteered to help co-ordinate landings today. He's in #developers.

cheers,
mike
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Removing restriction on mozilla-central

2009-12-09T16:13:58Z

On 8 Dez., 18:31, Mike Beltzner <beltz...@...> wrote:
> Hi,
>
> We're down to 26 code-related blockers for mozilla1.9.2/firefox3.6, the lion's share of which are in JavaScript. I'd like to propose that we lift the restriction on mozilla-central, returning us to a state where any reviewed patch can be landed, to allow many excellent pieces of technology (out-of-process plugins, Direct 2D, Web GL, Tab Matches in Awesomebar) to start landing and baking for a future release.
>
> If we do this, our sheriffs will need to be EXTRA vigilant in watching for test and build failures, and quite aggressive about backing out anything that's causing problems.
>
> Comments or questions should be sent today, and if we can all agree, we'll make the change later tonight or tomorrow morning.

Any update on this?
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Removing restriction on mozilla-central

2009-12-09T16:10:55Z

Any update on this?
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Thunderbird 3 is now available for download

2009-12-09T11:14:28Z

Will this eventually be available as an automatic upgrade from TB2? I
have no desire to go through all the headaches of upgrading I've read about.
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Thunderbird 3 is now available for download

2009-12-09T09:46:09Z

Am 08.12.2009 23:48, schrieb Mark Banner:
> Mozilla Messaging is happy to announce that Thunderbird 3 is now
> available for download:

Hi David, hi Mark, hi TB3 Team

Congratulations. TB3 is a great product and especially a great platform.

I know that a lot of work has gone into the backend, from which only
some parts are now visible to the user.
However, this prepares the ground for many new upcoming features and
updates, I've been waiting for.

Best wishes to the whole TB3 Team / Crew for the great work and all the
best for the next building stones. (Which are now coming much faster
with the new release schedule.) ;-)

Greetings from Switzerland,
Rolf
_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning

Re: Removing restriction on mozilla-central

2009-12-09T03:16:33Z

Hi,

On Tue, 2009-12-08 at 09:31 -0800, Mike Beltzner wrote:
> Hi,
>
> We're down to 26 code-related blockers for mozilla1.9.2/firefox3.6, the lion's share of which are in JavaScript. I'd like to propose that we lift the restriction on mozilla-central, returning us to a state where any reviewed patch can be landed, to allow many excellent pieces of technology (out-of-process plugins, Direct 2D, Web GL, Tab Matches in Awesomebar) to start landing and baking for a future release.
>
> If we do this, our sheriffs will need to be EXTRA vigilant in watching for test and build failures, and quite aggressive about backing out anything that's causing problems.
>
> Comments or questions should be sent today, and if we can all agree, we'll make the change later tonight or tomorrow morning.

This sounds like a good idea - on a somewhat related note, is this a
good time to poke someone to review my headless backend for inclusion?

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=446591
Repo: http://hg.mozilla.org/incubator/offscreen ('headless' branch)

--Chris

_______________________________________________
dev-planning mailing list
dev-planning@...
https://lists.mozilla.org/listinfo/dev-planning