It looks like we're managing to get SeaMonkey 1.1 stable enough for
shipping now, and right in time for the Christmas holidays we can
present you the first round of candidate builds for heavy testing.
Those candidate builds are here:
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/candidates-1.1/
If you got some free time in the next days, please help us test those
builds and report any major bugs, regressions and/or release blockers.
Merry Christmas,
Robert Kaiser
Please use more civilized language here, esp. when it's Christmas time.
Thanks!
Robert Kaiser
P.S.: candidate builds don't mean we won't take any fixes for the 1.1.x
tree any more, though 1.1 itself probably should be done unless we find
major bugs.
Respectfully, and specific to the mailnews part of SeaMonkey, I
disagree. There've been a dangerously high number of new email
weirdnesses observed since 1.1b (several with the potential to lead to
corruption and dataloss, and many others just giving a very unpolished
look (inconsistent unread count issues, Benoit's missing email
notifications e.a.)), and virtually no testing of how widespread these are.
At the risk of it being labeled as a pet-bug, something like bug 364189
is an issue that I believe would be completely unacceptable to ship with
if it's reproduceable. I'll freely admit that it could just be an issue
with my setup (I really hope so), but we don't *know*, and there've
simply been too many (high-risk) email backend changes since 1.1b, with
issues here only being detected by real world use, not incidental
testing, and there not being enough of that real world use.
I believe and recommend that the best course of action at this point
would be to do a 1.1b2 release (or label it rc1 if you prefer) to get
more solid testing, and not ship 1.1 final at the same time as
Thunderbird 2.0 (unless that testing doesn't result in any other
complaints about email use, in which case we could always relabel that
release as 1.1 final).
I know no one wants such a delay, but from where I'm sitting, looking
from a QA PoV, we at this point simply can't guarantee a good enough
level of quality for the SeaMonkey email client, and since the _suite_
aspect is what gives us most of the users we have, I don't think we
should drop the ball on such an important part of the program.
Sander
s/at/until/
Sander
Inconsistent unread counts (phantom messages in newsgroups for messages
cancelled on the server before being downloaded, requiring manual edit of the
<profile>/News/newsrc-news.mozilla.org or similar), have been there since
before Tb 1.0. It would be nice to fix that bug (on all Mozilla newsreaders)
but, well, I don't expect that fix any time soon.
> notifications e.a.)), and virtually no testing of how widespread these are.
> At the risk of it being labeled as a pet-bug, something like bug 364189
> is an issue that I believe would be completely unacceptable to ship with
> if it's reproduceable. I'll freely admit that it could just be an issue
> with my setup (I really hope so), but we don't *know*, and there've
> simply been too many (high-risk) email backend changes since 1.1b, with
> issues here only being detected by real world use, not incidental
> testing, and there not being enough of that real world use.
>
> I believe and recommend that the best course of action at this point
> would be to do a 1.1b2 release (or label it rc1 if you prefer) to get
> more solid testing, and not ship 1.1 final at the same time as
> Thunderbird 2.0 (unless that testing doesn't result in any other
> complaints about email use, in which case we could always relabel that
> release as 1.1 final).
> I know no one wants such a delay, but from where I'm sitting, looking
> from a QA PoV, we at this point simply can't guarantee a good enough
> level of quality for the SeaMonkey email client, and since the _suite_
> aspect is what gives us most of the users we have, I don't think we
> should drop the ball on such an important part of the program.
>
> Sander
Wouldn't it be good enough is SeaMonkey's mailnews component is (at least) as
good as Thunderbird? Then why couldn't they ship at the same time?
Best regards,
Tony.
> Inconsistent unread counts (phantom messages in newsgroups for messages
> cancelled on the server before being downloaded, requiring manual edit of the
> <profile>/News/newsrc-news.mozilla.org or similar), have been there since
> before Tb 1.0. It would be nice to fix that bug (on all Mozilla newsreaders)
> but, well, I don't expect that fix any time soon.
Its Christmas and Santa Bienvenu had a patch in his bag that should fix
that bug. https://bugzilla.mozilla.org/show_bug.cgi?id=298737#c35
--
best regards
I'll believe it when I see it (or rather, when I won't be seeing it anymore).
Yesterday I still had to fix the line for mozilla.support.firefox that way in
my News/newsrc-news.mozilla.org (for Tb 2.0b1, and I upgrade to the latest
branch nightly every 24 hours).
Best regards,
Tony.
Actually, many of us (including me) were and are using 1.8 branch for
all their mail on a daily basis and had no critical or blocker-looking
issues for a long time - and those that were reproducibale and bad
enough for others (I e.g. could reproduce the IMAP crasher but never
before did delete IMAP attachments) have been resolved as of now.
> At the risk of it being labeled as a pet-bug, something like bug 364189
> is an issue that I believe would be completely unacceptable to ship with
> if it's reproduceable.
That's the point. We have no report of it being reproducable in a
dataloss or other really harmful way (wrong unread count are IMHO a
different bug which bienvenu has been working on and he might even have
resolved a big part of its cause).
The reason why we're doing candidates is that we get widespread enough
testing to see if there are any showstoppers left that have not yet been
identified as such, and that includes your "pet bug" atm (as noone
except you seems to be able to see it at this moment).
> I know no one wants such a delay [...]
"such a delay" could mean a really harmful further delay of suiterunner
acitivities by binding workforce to 1.8 branch, and that is what makes
me most nervous.
Robert Kaiser
How does it delay suiterunner if SeaMonkey really is as stable as you're
saying?
For explain it for about the 27th time:
It binds workforce to the branch, and in a small team, all workforce
that is bound to anything else than suiterunner delays a suiterunner
release.
Robert Kaiser
Wouldn't that workforce devoted to 1.8 branch have a possitive effect
also in trunk? I mean, are we talking about bugs that show up ONLY in
SeaMonkey 1.1 but not 1.5, and thus fixing them in 1.1 is wasted time?
I really think that dataloss bugs, if any, should be fixed, as well as
cosmetic bugs that are easy for users to stumble upon. For instance,
mail folders (as opposed to newsgroups) message count bug should be
fixed IMHO. But I speak here just as a simple user.
Ricardo.
--
If it's true that we are here to help others,
then what exactly are the OTHERS here for?
Not always. There's a lot of code on the 1.8 branch that will die on
trunk. There are also features that have to be written differently for
1.8 branch than trunk.
> I mean, are we talking about bugs that show up ONLY in
> SeaMonkey 1.1 but not 1.5, and thus fixing them in 1.1 is wasted time?
>
For some, yes. Just worrying about the 1.1 release takes time too
though (checking the status of blocking bugs, poking people to see how
to fix them, etc.)
Chris
>I don't think you get my point. If SeaMonkey 1.1 really is as stable as
>you're saying, it doesn't need much work, and the time not needed to be
>spent on 1.1 can be spent on SuiteRunner.
I don't think you get his point.
If SM 1.1 is delayed, then it is obviously not as stable as KaiRo
currently believes it to be, so it needs work on thr branch which moves
away resources from suiterunner.
Simon
--
Sunbird/Lightning Website Maintainer:
http://www.mozilla.org/projects/calendar
Sunbird/Calendar blog: http://weblogs.mozillazine.org/calendar
So what? If he's wrong, and it's really not as stable as he believes it
to be, then it deserves attention.
The SeaMonkey Council seems to forget that we'll have to make do with
1.1 FOR ONE WHOLE YEAR. Delivering a release with a bad mailnews
back-end and lack of polish is just not justifiable.
mozilla.dev.planning
Gecko 1.9a2 scheduling
http://groups.google.com/group/mozilla.dev.planning/browse_thread/thread/e1965366514acc86/#
From: Vladimir Vukicevic
Date: Wed, Dec 20 2006 2:33 pm
In keeping with the goal of doing a Gecko 1.9 release every 4-6 weeks,
I propose that we plan for January 29 for the next release.
Folks, I know of two bugs in SM 1.1.RCx/Nightlies that are fixed right
Now in SM 1.5a. With Gecko 1.9, SM 1.5a already fixes whole Classes
of bugs that will never, Ever be fixed in SM 1.1/Gecko 1.8.1.
I have to trust the SM Council to be sure the truely serious bugs in
SM 1.1, including some UI and Mail/News bugs, are fixed. But, I believe
we may be at the point of Diminishing Returns with continued SM 1.1
development. Time to release SM 1.1 and move on.
With Gecko 1.9.a2 expected a month from now, SM 1.5 developers
need the next month, Jan. 2007, to prepare SM 1.5a/b for "release"
in early Feb. 2007, I presume.
Firefox 3, also with Gecko 1.9, is expected May-June 2007. I suppose
Thunderbird 3 would follow a few weeks after that.
Therefore, SM 1.5 can be out in 7-10 months, perhaps,
if SM 1.1 is released Now, even though imperfect,
so SM 1.5 developers can Keep Up
with the Gecko 1.9 and Ff/Tb 3 work.
Thank you,
Eddie
I'm fully with you that we should get 1.1 out right now, but at the
current rate of development, I wouldn't expect a suiterunner release in
the next two years. I hope a 1.1 final release will speed up development
a lot and make things look better, hopefully in the direction of what
you are talking about.
Robert Kaiser
>>> I don't think you get my point. If SeaMonkey 1.1 really is as stable as
>>> you're saying, it doesn't need much work, and the time not needed to be
>>> spent on 1.1 can be spent on SuiteRunner.
>>
>> I don't think you get his point.
>>
>> If SM 1.1 is delayed, then it is obviously not as stable as KaiRo
>> currently believes it to be, so it needs work on thr branch which moves
>> away resources from suiterunner.
>
>So what? If he's wrong, and it's really not as stable as he believes it
>to be, then it deserves attention.
Please read my message before you reply to it. It says exactly what you
just said.
Yes. So where's the problem?
If we ship 1.1 early with backend mailnews bugs that get fixed after
release, then they'll be fixed in 1.1.1, so I don't really see the
relevance of "ONE WHOLE YEAR". We shouldn't ship something that's
broken or that has significant regressions from 1.0 because we shouldn't
ship busted builds. That's it.
--
Andrew Schultz
aj...@buffalo.edu
http://www.sens.buffalo.edu/~ajs42/
How will they get fixed in 1.1.1? The nature of such releases is to only
accept low risk, high reward fixes.
I suggest we move to suggestions on how to make a RSN RC and release of
1.1 a reality.
What's the bug number of this bug? I think I see it too sometimes.
It's bug 365180.
https://bugzilla.mozilla.org/show_bug.cgi?id=365180
We don't control the backend. The TB folks do. And they'll be more
liberal with accepting patches because they haven't released their 2.0
yet. And early point releases do often take bug fixes in addition to
security fixes.
But are there release notes somewhere? Or a Bug search that will turn up
all the changes?
Thank You
David (Still learning my way around this place.)
OK. I found this list.
http://www.mozilla.org/projects/seamonkey/releases/seamonkey1.1b/
Is there anything else?
> If you got some free time in the next days, please help us test those
> builds and report any major bugs, regressions and/or release blockers.
I've been using the candidate build on Windows for the past week and
today I noticed that some emails are not being downloaded automatically.
I have Check for new messages every 10 minutes and Automatically
download new messages checked in my Server settings for all my email
accounts. When I manually Get All New Messages, I get the messages, but
it seems they are not always downloaded automatically.
Maybe others are seeing the same problem? I suppose selecting Get All
New Messages now and seeing if you suddenly get several days of messages
would confirm the problem.
POP3?
--
Andrew Schultz
ajsc...@verizon.net
http://www.sens.buffalo.edu/~ajs42/
Bug 366014?
I just filed it.
Tab previews hide the popup menu when you want to edit an item from the
personal toolbar. Mac 10.4.8, SM 1.5rc
> Tab previews hide the popup menu when you want to edit an item from
> the personal toolbar. Mac 10.4.8, SM 1.5rc
1.5rc? Off topic for this thread ;-)
Are you saying that the tooltip for an element that should be obscured
by a context menu is still firing? What about CSS hover effects? That
is, if you have a context menu open, do CSS hover effects apply to the
elements under the context menu as if the menu wasn't there?
--
Warning: May contain traces of nuts.
The mailnews interface is very slow. It takes more than 2-3 seconds to
go to next unread message. Is there a bug for this ? I think 1.1
shouldn't be released with this. 1.5 trunk release doesn't have this bug.
1.1 RC Build ID: 2006123109
Yes, POP Mail server pop.sbcglobal.yahoo.com
Yes to the first question. I don't know enough about web design to
answer the rest.
Take a look at the Christmas release thread further below for more
information.
Thanks, this helps. Will final Seamonkey 1.1 have this patch?
OK. I've found the answer. Yes :)
Well, I don't know about the Mac theme, but at least with the Modern
theme, you should find several elements respond to being hovered with
the mouse. If you can arrange for a context menu to partially cover one
of these elements, then you can mouse over the menu, and see if the
hover effect is still triggered.
In order for the page to appear in the same browser window, I had to
right-click the link and select "Open link in new tab". I don't know if
this is a bug, but when the same was clicked in SM 1.0.7, it opened in
the same window.
A crasher.
You want to disable JavaScript for security reasons.
Yet you do, & you are liable to crash.
My bug, or many similar to it.
This does crash in SeaMonkey 1.1b.
Better said, it crashes in MOST builds of SeaMonkey 1.1b.
There are some builds where there was no crash.
With some builds of 1.1b, there is no crash.
There is no crash with 1.5a (in my very, very limited testing).
So here we are, about to have a release of 1.1 - that crashes.
And can crash with regularity. Easily. No machinations required.
Simply disable JavaScript. Happen to visit a website - it happens at
many websites, & crash, bang, boom.
This is a "drive by" crasher that should not be.
Why can't we get a release version of 1.1 that does not crash due to
this or related bugs?
Bug 362603 - Illegal Operation In Plug-in, Windows Media Player
Plug-in DLL (WMP plugin, embedded, crash, JavaScript disabled)
https://bugzilla.mozilla.org/show_bug.cgi?id=362603
Because it is in core code, which SeaMonkey can't influence at all, and
core developers apparently also shipped Firefox 2 with that bug, so it
seems not to be severe enough for them to block major releases.
Robert Kaiser
Yes, that's new. I noted it a couple days ago. mailnews now checks the
"Links from external applications" preference in Navigator > Tabbed
Browsing to know how to handle links instead of just passing it to the
browser.
I've just put a new, hopefully final, round of candidate builds there,
care to fetch the builds dated January 8 (mirrors should have them soon).
Please test them thoroughly, I hope we find no significant regressions
and those are the binaries we can ship as the 1.1 release.
Robert Kaiser
Is there a list of changes between the two RCs?
We did actually three rounds of candidate builds so far, and there is no
official list of changes between any of them, you got to look into
bonsai for that. The most important change for the neweset round is the
update of copyright strings to 2007.
Robert Kaiser
Hi guys !
I installed RC 2 right now and see Mail component don`t show correctly
the webpage I select to open when select e-mail acount.
The webpage is OK at nagivator, but Mail componet has problem to show.
I was using Seamonkey 1.0.7 before.
I did download of this build:
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/2007-01-08-01-mozilla1.8/
It shows nothing? Or partially loads the page? My mail window seems to
like selecting something when I open it so I get whatever is appropriate
for that on the right hand side instead of the start page. If you set
it to the default page (Restore Default) does that work for you?
I have the 12/31 versions installed for me and a few folks.
But a list of bug fixes and enhancements would be nice so I could
specifically check out some things. (Is the "some web links in email
don't do anything" still there?) Then I'd look for specific things. I
have given it to several other who are driving blind but in some ways
that's good as they might find things those "in the know" would miss.
If there's a bugzilla search I can do please let me know. I'll please
ignorance to a lot of the developer ways around here.
Best way to have that fixed anytime soon would be to file a bug... I
haven't seen anything like that recently.
> If there's a bugzilla search I can do please let me know. I'll please
> ignorance to a lot of the developer ways around here.
Here's the bonsai list KaiRo was talking about:
http://bonsai.mozilla.org/cvsquery.cgi?module=SeaMonkeyAll&branch=MOZILLA_1_8_BRANCH&date=explicit&mindate=12%2F31%2F2006
(everything since 12/31)
You can query bonsai here:
http://bonsai.mozilla.org/cvsqueryform.cgi
You could do a bugzilla query too, but it'd be hard to make a query that
didn't miss anything.
--
Andrew Schultz
aj...@buffalo.edu
http://www.sens.buffalo.edu/~ajs42/
Kent James
I'm seeing a strange bug in mail compose with BCC recipients.
Compose > click address > add a "to" recipient > add five or six BCC
recipients.
Using the scroll wheel shows all of the BCC, but click the down
arrow on the scroll bar and only three are shown.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2pre)
Gecko/20070108 SeaMonkey/1.1
Zeb
This was
https://bugzilla.mozilla.org/show_bug.cgi?id=365234
The fix landed on the branch last night.
It happens for To/CC as well as BCC. And for manually entered addresses
(in addition to addresses from the dialog).
I set "http://www.netvasco.com.br" to Mail Start Page and the site is
also partially loaded.
SM 1.0 series always load the same site very well.
Yes, the default page work well
(chrome://messenger/content/start.xhtml), but I like set to load my
soccer team news page :^)
Before, I try webpage
"http://ultimosegundo.ig.com.br/paginas/grandepremio/" but don`t work
too. The problem is the same: webpage at SM Mail only was partially
loaded.
> Zeb wrote:
>> I'm seeing a strange bug in mail compose with BCC recipients.
>> Compose > click address > add a "to" recipient > add five or six BCC
>> recipients.
>> Using the scroll wheel shows all of the BCC, but click the down
>> arrow on the scroll bar and only three are shown.
>
> This was
> https://bugzilla.mozilla.org/show_bug.cgi?id=365234
> The fix landed on the branch last night.
>
> It happens for To/CC as well as BCC. And for manually entered addresses
> (in addition to addresses from the dialog).
Thanks Andrew.
Zeb
Bug Duplicate for SeaMonkey
https://bugzilla.mozilla.org/show_bug.cgi?id=365769 "Run Junk Mail
Controls on Folder" ??
Lukas Novotny
>I set "http://www.netvasco.com.br" to Mail Start Page and the site is also partially loaded.
>
>
I think we enhanced the content blocker, which might be affecting remote
start pages. (Sorry, but I didn't think of that when I reviewed it).
> Kent James napsal(a):
>
>> Bug #324953, which is listed as Thunderbird front end trunk only,
>> affects Seamonkey on the MOZILLA_1_8_BRANCH, including the recent 1.1
>> release candidate. That is, the command "Run Junk Mail Controls" is
>> completely broken.
>
> Bug Duplicate for SeaMonkey
> https://bugzilla.mozilla.org/show_bug.cgi?id=365769 "Run Junk Mail
> Controls on Folder" ??
Actually bug 324953 was only supposed to cover the Mark Messages option;
I have no idea about Run Junk Mail Controls on Folder.
Please file a bug on that, as Neil said, it might be connected to remote
content filters.
As long as the default start page loads and works alright, it doesn't
block the release in my eyes, even if it's a valid bug (and a
regression). We should try to get a fix in 1.1.x though, if reasonably
possible.
Robert Kaiser
"Run Junk Mail Controls on Folder" WFM on a self-compiled Linux build,
the Mark Messages option is broken here as well though.
If it's the mark messages option only, I think we should get a fix in
for 1.1.x but don't need to blocker.
I'd like confirmation on the "Run on Folder" option though.
Robert Kaiser
Problem: Directory dates for "candidates-1.1/" not updating. See below.
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/
[DIR] candidates-1.0.7/ 12-Dec-2006 10:22 -
[DIR] candidates-1.1/ 23-Dec-2006 18:23 <- 08-Jan-2007?
[DIR] candidates-1.1a/ 28-Aug-2006 03:47 -
[DIR] candidates-1.1b/ 06-Nov-2006 07:22 -
[DIR] contrib/ 10-Jan-2007 09:25 -
[DIR] experimental/ 31-Oct-2006 11:46 -
[DIR] latest-mozilla1.8.0/ 10-Jan-2007 20:55 <- always updated
[DIR] latest-mozilla1.8/ 10-Jan-2007 17:20 <- always updated
[DIR] latest-trunk/ 10-Jan-2007 10:39 <- always updated
Eddie Maddox
This is no problem, but intended. Only our candidate builds go there,
that's why the directory is called that.
The only directories getting regularly updated are the latest-* ones, as
those contain the latest nightly builds, all others usually aren't
updated at all. The candidates-* directories are updated only if we
realize we have some problem with the builds and can not use those
builds as the release builds.
Robert Kaiser
I think this is bug 360814.
The candidates only update when Robert respins candidates. The last
time he did that was Jan 8. I think we're trying to do another respin
soon to pick up the fix for the bug Zeb mentioned.
Yes, sounds like that. And with it set to block TB2, it will probably be
fixed in SeaMonkey 1.1.1 as well.
Robert Kaiser
In theory.
In practice, they are Not updating, as shown above, and again below:
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/
candidates-1.1/ 23-Dec-2006 18:23 <- Not updated
http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/candidates-1.1/
[DIR] linux-xpi/ 08-Jan-2007
04:31 -
[ ] seamonkey-1.1.en-US.linux-i686.installer.tar.gz 08-Jan-2007
04:46 14M
[ ] seamonkey-1.1.en-US.linux-i686.stub-installer.tar.gz 08-Jan-2007
04:46 89K
[ ] seamonkey-1.1.en-US.linux-i686.tar.gz 08-Jan-2007
04:55 14M
[ ] seamonkey-1.1.en-US.mac.dmg 08-Jan-2007
00:33 22M
[ ] seamonkey-1.1.en-US.win32.installer.exe 08-Jan-2007
14:58 12M
[ ] seamonkey-1.1.en-US.win32.stub-installer.exe 08-Jan-2007
14:58 264K
[ ] seamonkey-1.1.en-US.win32.zip 08-Jan-2007
15:01 11M
[ ] seamonkey-1.1.source.tar.bz2 08-Jan-2007
05:30 33M
[ ] seamonkey-1.1.source.tar.gz 08-Jan-2007
05:49 43M
[DIR] windows-xpi/ 08-Jan-2007
15:03
###,
Eddie
"only when Robert respins candidates"
I don't see anything that disputes that.
> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/
> candidates-1.1/ 23-Dec-2006 18:23 <- Not updated
that's the date on the directory. You clearly determined that the
contents of the directory are newer than that.
Nobody is disputing that.
>> http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/
>> candidates-1.1/ 23-Dec-2006 18:23 <- Not updated
>
> that's the date on the directory. You clearly determined that the
> contents of the directory are newer than that.
Obviously - he said that in the original post. The problem he is
reporting is that, as you have agreed, the directory date does not match
the date of the contents.
I think the answer is that it's actually quite normal for the directory
date to be older than the date of the content. However, for Mozilla ftp
it is unusual, as the automated process which produces the nightly builds
does touch the directory as well, so for nightly builds the directory date
usually matches the content.
--
Michael
With the risk of repeating myself ;-)
I've just uploaded another new, hopefully really final, round of
candidate builds there, already generated from the release tag (and we
hope we don't need to move around the tags).
Care to fetch the builds dated January 11th or 12th.
Please test those build thoroughly, I hope we find no significant
regressions any more and those are the now really binaries we can ship