SeaMonkey 1.1 planning
Robert Kaiser
As Firefox people are nearing their first beta in the 1.8.1 cycle (code
freeze currently scheduled for July 5th, release for 11th) it gets time
for us to think a bit more about the SeaMonkey 1.1 release.
While https://bugzilla.mozilla.org/show_bug.cgi?id=sm1.1 has a nice list
of dependencies and nominations, not really much has been done on those
new features, so I'd like some feedback on what you think this release
will realistally be like.
The following questions need to be answered IMHO:
1) What has already landed on the 1.8 branch that makes current builds
differ from 1.0 in a way that is worthwhile mentioning?
2) What patches can we still realistically push into 1.1 that make a
signifcant difference? What things do we really want/need to land there
before a release? What do we need to push in what way to get this done?
3) What timetable (perhaps relative to FF/Gecko release plans) do we
think we can set for alpha, beta and final releases of SeaMonkey 1.1?
Please reply to this post with your opinion on those, so that we can
really plan this next bigger release soon.
Greetings,
Robert Kaiser
Andrew Schultz
> 1) What has already landed on the 1.8 branch that makes current builds
> differ from 1.0 in a way that is worthwhile mentioning?
A big part of this is stability and bug fixing (polish). We'll pick up
gecko 1.8.1 fixes that were too scary for 1.8.0. I landed some
autocomplete bug fixes on 1.8.1.
Linux will get a startup script that talks to the already-running
process to open a new window instead of always trying to start a new
process.
> 3) What timetable (perhaps relative to FF/Gecko release plans) do we
> think we can set for alpha, beta and final releases of SeaMonkey 1.1?
This depends a lot on the answer to #2. I think, as it is now, we could
move pretty quickly through alpha and beta given that we haven't taken
anything scary on the branch.
--
Andrew Schultz
ajsc...@verizon.net
http://www.sens.buffalo.edu/~ajs42/
Robert Kaiser
> Robert Kaiser wrote:
>> 1) What has already landed on the 1.8 branch that makes current builds
>> differ from 1.0 in a way that is worthwhile mentioning?
>
> gecko 1.8.1 fixes that were too scary for 1.8.0.
Anything concrete that is significant there?
> I landed some
> autocomplete bug fixes on 1.8.1.
>
> Linux will get a startup script that talks to the already-running
> process to open a new window instead of always trying to start a new
> process.
Those two sound like small, but significant things. If we have piled up
enough of such things, they may warrant the .1 release as well, even if
we might be missing major new features.
One thing we might want to mention there is that we have a new, updated
version of ChatZilla on branch, which is a significant change as well.
The main purpose I see in this thread is to evaluate how much sense the
1.1 release makes with the stuff we can realistically provide in the
release, and based on that find out a possible timetable.
Robert Kaiser
Philip Chee
> While https://bugzilla.mozilla.org/show_bug.cgi?id=sm1.1 has a nice list
> of dependencies and nominations, not really much has been done on those
> new features, so I'd like some feedback on what you think this release
> will realistally be like.
> 2) What patches can we still realistically push into 1.1 that make a
> signifcant difference? What things do we really want/need to land there
> before a release? What do we need to push in what way to get this done?
The drag'n'drop toolbars has a patch so it guess it's doable in the 1.1
timeframe. Any chance of getting customizable toolbarbuttons to go with
this or is this dependent on toolkit?
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Glory is fleeting, but obscurity is forever...
* TagZilla 0.059
Robert Kaiser
> The drag'n'drop toolbars has a patch so it guess it's doable in the 1.1
> timeframe. Any chance of getting customizable toolbarbuttons to go with
> this or is this dependent on toolkit?
Those issues are othogonal, and the current patch causes big leaks duie
to XBL stuff and therefore can't be applied to branch (at least that's
what I remember from what CTho told on IRC).
Robert Kaiser
Manuel Reimer
> 2) What patches can we still realistically push into 1.1 that make a
> signifcant difference? What things do we really want/need to land there
> before a release? What do we need to push in what way to get this done?
Is this one:
https://bugzilla.mozilla.org/show_bug.cgi?id=286628
already in SeaMonkey? I really *need* this one in SeaMonkey 1.1!
CU
Manuel
--
Privatsphäre bald Geschichte? Einschränkung der Rechte durch DRM?
Informieren, bevor es zu spät ist! Es sind auch deine Rechte!
www.stoppt-die-vorratsdatenspeicherung.de www.stop1984.com
www.againsttcpa.com www.privatkopie.net www.foebud.org
Neil
> Is this one:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=286628
>
> already in SeaMonkey? I really *need* this one in SeaMonkey 1.1!
It landed on trunk last week, but it looks as if David is waiting for
positive feedback for landing it on the branch.
--
Warning: May contain traces of nuts.
Mark Banner
> Hi SeaMonkey developers,
>
> The following questions need to be answered IMHO:
>
> 1) What has already landed on the 1.8 branch that makes current builds
> differ from 1.0 in a way that is worthwhile mentioning?
From an address book point of view, which I know isn't necessarily that
significant, but anyway:
- Various Improvements to the LDAP directory download dialog (bugs
300968, 133883, 340560)
- When address book name is Japanese character(doesn't contain ASCII
alpha-numeric), address book is lost (bug 316812)
- Should be possible to move/copy address cards to different address
books (bug 35837)
The last of these is most significant as it means that things are now
correctly copied and moved within the address book. It helped solve
quite a few bugs.
> 2) What patches can we still realistically push into 1.1 that make a
> signifcant difference? What things do we really want/need to land there
> before a release? What do we need to push in what way to get this done?
How's the RSS patch? I thought it got review, but I think this would be
the real plus.
From the address book side, I'm not aware of anything else for 1.1,
there's a whole load of changes on trunk that aren't worth/can't easily
be ported to the branch.
> 3) What timetable (perhaps relative to FF/Gecko release plans) do we
> think we can set for alpha, beta and final releases of SeaMonkey 1.1?
Any ideas on the Thunderbird timescale? I'm sure they are going to have
some fixes in the alphas/betas.
Standard8
Neil
> Any ideas on the Thunderbird timescale?
Typically a week after Bon Echo.
> I'm sure they are going to have some fixes in the alphas/betas
We'll check their release notes for any changes in common code right ;-)
Robert Kaiser
> How's the RSS patch? I thought it got review, but I think this would be
> the real plus.
Ian should know, but this is something I also would like to see on
branch, if possible.
And thanks for your list about addressbook stuff, this is exactly the
style I'd like to see, so that we know how much sense 1.1 makes.
Robert Kaiser
Torsten Bondieck
Hi Robert,
> As Firefox people are nearing their first beta in the 1.8.1 cycle (code
> freeze currently scheduled for July 5th, release for 11th) it gets time
> for us to think a bit more about the SeaMonkey 1.1 release.
>
> While https://bugzilla.mozilla.org/show_bug.cgi?id=sm1.1 has a nice list
> of dependencies and nominations, not really much has been done on those
> new features, so I'd like some feedback on what you think this release
> will realistally be like.
can you announce this also in german mozilla groups?
Torsten
Robert Kaiser
> can you announce this also in german mozilla groups?
German newsgroups are user-oriented, just like our support newsgroup on
this server. This is a question to the really active developers though,
I don't want users to tell us what we should possibly do, I want real
realistic facts from the developers, that's why I only asked here.
We'll announce in the German newsgroups once we have an Alpha.
Robert Kaiser
Chris Thomas
It's mostly fixable - basically, my patch let the toolbars be created
normally, then moves them around. Firefox actually creates the toolbars
in place with JS which largely avoids that class of problems. An
updated patch would only leak a window in which you dragged a toolbar
since opening the window (whereas the current patch leaks every window
that has a toolbar that's not in the default position).
I was waiting for the migration to toolkit toolbars (to avoid getting
severely bitrotted), and I thought that would be quick, but I was very
wrong :(. Now that the migration is finally happening, I'd be
interested in working on bug 15322 again, but can't make any guarantees
since I'm starting a full-time job in a week.
Chris
Robert Kaiser
> Hi SeaMonkey developers,
>
> As Firefox people are nearing their first beta in the 1.8.1 cycle (code
> freeze currently scheduled for July 5th, release for 11th) it gets time
> for us to think a bit more about the SeaMonkey 1.1 release.
Firefox people have a release candidate out for FF2beta1 now, what
should we do wrt 1.1? Should we try to get ready for an Alpha now/soon?
Robert Kaiser
Mark Banner
> Firefox people have a release candidate out for FF2beta1 now, what
> should we do wrt 1.1? Should we try to get ready for an Alpha now/soon?
FWIW: I believe Thunderbird are also considering doing their first alpha
soon after ff beta 1 or at the same time.
I think it'd really be nice to know if/when RSS support is likely to
arrive, and if we can push it in for alpha - I think that would be a
feature worth waiting for but at the same time, I agree we don't want to
delay too long.
Standard8
Robert Kaiser
> I think it'd really be nice to know if/when RSS support is likely to
> arrive, and if we can push it in for alpha - I think that would be a
> feature worth waiting for but at the same time, I agree we don't want to
> delay too long.
I haven't seen any movement on this for quite a while, so I wouldn't
expect to get it that fast :(
Robert Kaiser
Philip Chee
Isn't there a working patch? It's just a port of Blunderbird's newsblog.
All that needs to be done is to fork the bits that mscott doesn't want
touched.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]"If atheism is a religion, then bald is a hair color."
* TagZilla 0.059
Robert Kaiser
> On Sat, 08 Jul 2006 21:49:38 +0200, Robert Kaiser wrote:
>> Mark Banner schrieb:
>
>>> I think it'd really be nice to know if/when RSS support is likely to
>>> arrive, and if we can push it in for alpha - I think that would be a
>>> feature worth waiting for but at the same time, I agree we don't want to
>>> delay too long.
>
>> I haven't seen any movement on this for quite a while, so I wouldn't
>> expect to get it that fast :(
>
> Isn't there a working patch? It's just a port of Blunderbird's newsblog.
> All that needs to be done is to fork the bits that mscott doesn't want
> touched.
Nah, forking just because of forking is worng. And we probably wantr to
use the new global feeds service instead of reinventing the wheel...
Robert Kaiser
Manuel Reimer
> Firefox people have a release candidate out for FF2beta1 now, what
> should we do wrt 1.1? Should we try to get ready for an Alpha now/soon?
Do we depend on Firefox or Thunderbird? Publish 1.1 if it's ready and
not if something else is ready.
CU
Manuel
Robert Kaiser
We don't depend on FF/TB, we only depend on a (semi-)stable
Gecko/platform for (pre-)releases, and that is synched with Firefox, as
you might know.
Additionally, we need to go into Alpha phase soon if we want to do a 1.1
release this fall, and I think that's still our intention, as the next
big release ("1.5") is targeted early next year.
Robert Kaiser
P.S.: How far progressed is your theme work? Are we in a stage where we
can review something to get your new icon set into Classic? This would
be something still nice to have for 1.1, IMHO.
Manuel Reimer
> P.S.: How far progressed is your theme work? Are we in a stage where we
> can review something to get your new icon set into Classic? This would
> be something still nice to have for 1.1, IMHO.
Yes, I could publish screenshots. Sorry for being absent some time
again. As you know we are building a house, which takes most of my spare
time.
But I aggree with you, that it would be great to have the new icons in
1.1. I'll do my best to make this possible!
There are still two issues in the theme where I don't know a good
solution, but maybe we can talk about this via IRC. As soon as all
issues are solved, I'll start having a look at the CSS-part (which is
also nearly finished, but there may be minor issues left).
A little problem may be, that we had planned to use the global part from
toolkit. As we won't be on toolkit with 1.1, I think we have to publish
with the "old global" part again (and this part needs rework, too).
CU
Manuel
Neil
> A little problem may be, that we had planned to use the global part
> from toolkit. As we won't be on toolkit with 1.1, I think we have to
> publish with the "old global" part again (and this part needs rework,
> too).
IMHO the toolkit global is worse than Classic global, at least on
Windows, which is the only place I've seen it; I hear it's pretty good
on the Mac, though.
Robert Kaiser
> Robert Kaiser wrote:
>> P.S.: How far progressed is your theme work? Are we in a stage where
>> we can review something to get your new icon set into Classic? This
>> would be something still nice to have for 1.1, IMHO.
>
> Yes, I could publish screenshots. Sorry for being absent some time
> again. As you know we are building a house, which takes most of my spare
> time.
Sure, I know how much work that is...
Anyways, having the screen shots publicly to discuss them would be nice.
Even better would be to have a patch we can review and apply ;-)
> But I aggree with you, that it would be great to have the new icons in
> 1.1. I'll do my best to make this possible!
Thanks!
> There are still two issues in the theme where I don't know a good
> solution, but maybe we can talk about this via IRC. As soon as all
> issues are solved, I'll start having a look at the CSS-part (which is
> also nearly finished, but there may be minor issues left).
Sure, though I think we can fix "minor issues" even after checkin (or
during reviews) - esp. as there are more eyes on that stuff then.
> A little problem may be, that we had planned to use the global part from
> toolkit. As we won't be on toolkit with 1.1, I think we have to publish
> with the "old global" part again (and this part needs rework, too).
Sure, we'll have to look into that for non-toolkit-based versions, but
as global doesn't have as many icons as the rest of the theme, I think
it's easier to care about, actually.
Robert Kaiser
Robert Kaiser
> 3) What timetable (perhaps relative to FF/Gecko release plans) do we
> think we can set for alpha, beta and final releases of SeaMonkey 1.1?
It looks to me like we have a bunch of improvements esp. in the mailnews
and Gecko areas that have already landed on the 1.8 tree, and we don't
have signs of any bigger stuff that will still be able to land there, so
I'd be very much for releasing an Alpha soon (perhaps aligned with Gecko
1.8.1b2?) and then go for a Beta and final in the next months.
What's your opinion on that?
Robert Kaiser
Justin Wood (Callek)
To me, sounds good.
If anyone here wants to actually work on any of those "like to have"
features for 1.1, please do so; and do so fast so we can get them in
before a 1.1; I won't ask for any of them to block 1.1
~Justin Wood (Callek), lowly developer.
Chris Thomas
> Robert Kaiser wrote:
>> Robert Kaiser schrieb:
>>> 3) What timetable (perhaps relative to FF/Gecko release plans) do we
>>> think we can set for alpha, beta and final releases of SeaMonkey 1.1?
>>
>> It looks to me like we have a bunch of improvements esp. in the
>> mailnews and Gecko areas that have already landed on the 1.8 tree, and
>> we don't have signs of any bigger stuff that will still be able to
>> land there, so I'd be very much for releasing an Alpha soon (perhaps
>> aligned with Gecko 1.8.1b2?) and then go for a Beta and final in the
>> next months.
>>
>> What's your opinion on that?
>>
>> Robert Kaiser
>
> To me, sounds good.
I agree.
> If anyone here wants to actually work on any of those "like to have"
> features for 1.1, please do so; and do so fast so we can get them in
> before a 1.1; I won't ask for any of them to block 1.1
>
> ~Justin Wood (Callek), lowly developer.
Bug 15322 - toolbar reordering: most likely not happening. Neil didn't
seem inclined to have the new toolkit toolbars on 1.8, and I'm not going
to write the same feature twice (for both xpfe and toolkit toolbars).
If someone wants to enable customizability, though, that should actually
be pretty easy, since there's just a JS file that needs to be stolen
(and reviewed).
Bug 19437 - move/delete/edit bookmarks in menus: I didn't actually
realize what this was asking for at the time... I only think you should
get context menu and drag-drop. I am unlikely to make progress on this
Bug 50504 - context menu for more bookmarks stuff: subfolders and PTF
overflow need this
Bug 71105 - biff w/o first opening mailnews:probably not happening, I
don't think anyone has the know-how
Bug 90315 - coloration for nested quotes: seems like it should be
possible... maybe Mnyromyr would be interested in writing it
Bug 113934 - cross-window tab drags: we need to find out if Jag's patch
is acceptable. I think it's worthwhile, even with the caveats.
Bug 152391 - undo close tab: needs someone to look at the Firefox
implementation, fix it, and port it
Bug 255834 - RSS: I thought this was going to happen ages ago :(
Bug 270443 - infobar: not happening. I think someone should port the
new toolkit replacement though.
Bug 288764 - hiding advanced prefs: nowhere near close
Philip Chee
> It looks to me like we have a bunch of improvements esp. in the mailnews
> and Gecko areas that have already landed on the 1.8 tree, and we don't
> have signs of any bigger stuff that will still be able to land there, so
> I'd be very much for releasing an Alpha soon (perhaps aligned with Gecko
> 1.8.1b2?) and then go for a Beta and final in the next months.
Is the trunk autocomplete.xml that supports Firefox/toolkit syntax
available in SeaMonkey 1.1? If not I think it should be. It's working
fine in SeaMonkey 1.0.3 currently (via xSidebar) with no problems.
However what I want is to package the form-history datasource and the
associated interfaces:
<http://www.xulplanet.com/references/xpcomref/ifaces/nsIFormHistory.html>
<http://www.xulplanet.com/references/xpcomref/comps/c_autocompletesearch1nameformhistory.html>
Since the main use of the autocomplete textbox by extension writers is
in conjuction with this datasource and interface.
I think all that needs to be done is to change the build scripts to
build these components, generate the XPT and package the resulting files
in the installer/zipbuilds.
One sticking point however is that the nsIFormHistory interface is only
available from @mozilla.org/satchel/form-history;1 and the Suite doesn't
build satchel, I don't think.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]I could be chasing an untamed ornithoid without cause.
* TagZilla 0.059
Philip Chee
> Bug 15322 - toolbar reordering: most likely not happening. Neil didn't
> seem inclined to have the new toolkit toolbars on 1.8, and I'm not going
> to write the same feature twice (for both xpfe and toolkit toolbars).
> If someone wants to enable customizability, though, that should actually
> be pretty easy, since there's just a JS file that needs to be stolen
> (and reviewed).
How does this work? I've got a recent trunk build. And I don't see any
differences. And I can't drag and drop any toolbar/menubar?
> Bug 90315 - coloration for nested quotes: seems like it should be
> possible... maybe Mnyromyr would be interested in writing it
We can probably steal the code from the quote-colors extension if we ask
politely.
> Bug 255834 - RSS: I thought this was going to happen ages ago :(
This is the newsblog patch right? I think there were some concerns about
forking the code.
I want to see support for livemarks metadata in the bookmarks module.
Note not the livemarks functionality itself. RSS extensions for firefox
usually package their own feed engines, but many of them leverage on the
Firefox bookmarks system to store their feed metadata via the livemark
properties. Although natively our direction is to go with the
Thunderbird newsblog extension, it would be a win in terms of RSS
extension developers if we could support all the properties from the
Firefox bookmarks datasource.
Also once the newsblog code is in, it would be SMOP to reimplement
livemarks by leveraging on the newsblog code.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]"Listen, have you seen the dolphins yet?" -Geordi
* TagZilla 0.059
Robert Kaiser
> Bug 255834 - RSS: I thought this was going to happen ages ago :(
And now that we build the feeds parser service by default, the existing
patch probably should be completely rewritten to use that - and IanN
doesn't seem to have much time to work on it :(
I hope we'll get it at least in time for "1.5"
> Bug 270443 - infobar: not happening. I think someone should port the
> new toolkit replacement though.
I hope we'll finally get this for suiterunner, at least...
Robert Kaiser
Neil
> Bug 71105 - biff w/o first opening mailnews:probably not happening, I
> don't think anyone has the know-how
This should just be a case of registering the account manager when we
start listening to biff notifications (in mailTasksOnLoad).
Neil
>Is the trunk autocomplete.xml that supports Firefox/toolkit syntax available in SeaMonkey 1.1?
>
Yes, as is the XUL filepicker autocompletion.
Chris Thomas
> On Fri, 21 Jul 2006 18:22:54 -0500, Chris Thomas wrote:
>
>> Bug 15322 - toolbar reordering: most likely not happening. Neil didn't
>> seem inclined to have the new toolkit toolbars on 1.8, and I'm not going
>> to write the same feature twice (for both xpfe and toolkit toolbars).
>> If someone wants to enable customizability, though, that should actually
>> be pretty easy, since there's just a JS file that needs to be stolen
>> (and reviewed).
>
> How does this work? I've got a recent trunk build. And I don't see any
> differences. And I can't drag and drop any toolbar/menubar?
You need to specifically build suiterunner, and you probably don't want
to do that unless you want a pretty broken browser or are interested in
helping out with it.
>> Bug 90315 - coloration for nested quotes: seems like it should be
>> possible... maybe Mnyromyr would be interested in writing it
>
> We can probably steal the code from the quote-colors extension if we ask
> politely.
Browsing through its code, it looks like it waits for the message to be
loaded, then walks over the messages's body nodes and colors them based
on depth. I don't think that would be considered a good solution for
the program itself (which, arguably, should just spit out quote depths
into the HTML it's writing).
That's actually the problem for a lot of interesting extensions - there
are workarounds/hackarounds that give good-looking results, but they're
not OK to use in the official tree.
Maybe we should have a list of officially-recommended extensions...
Chris
Rich Gray
...
> That's actually the problem for a lot of interesting extensions - there
> are workarounds/hackarounds that give good-looking results, but they're
> not OK to use in the official tree.
>
> Maybe we should have a list of officially-recommended extensions...
>
> Chris
I wonder if it would be possible to have a SeaMonkey Plus, a version
of SeaMonkey that came with a modest set of extensions preloaded?
This would cater to those who want a bigger kitchen sink but don't
want to be continually messing with finding extensions and keeping
them updated.
--
Rich
SeaMonkey - Surfing the net has never been so suite!
Chris Thomas
That doesn't sound like a bad idea. I'm not sure how it would be done
though, especially with installers.
Chris
Stephen Bounds (GuruJ)
> Rich Gray wrote:
>> Chris Thomas wrote:
>> ...
>>> That's actually the problem for a lot of interesting extensions -
>>> there are workarounds/hackarounds that give good-looking results, but
>>> they're not OK to use in the official tree.
>>>
>>> Maybe we should have a list of officially-recommended extensions...
>>>
>> of SeaMonkey that came with a modest set of extensions preloaded?
>> This would cater to those who want a bigger kitchen sink but don't
>> want to be continually messing with finding extensions and keeping
>> them updated.
>>
>
> That doesn't sound like a bad idea. I'm not sure how it would be done
> though, especially with installers.
A while ago I built an NSIS installer which installed Mozilla 1.5 and
allowed the user to select which XPIs they wanted installed (eg.
Venkman, DOM inspector).
This could be the basis of a modular SeaMonkey install. Unfortunately,
most extension XPIs assume user interaction which isn't suitable for an
automated installer, but it shouldn't be too hard to modify the
install.js to run automatically for the extensions we want.
If this is of interest, I'm happy to contribute the work I've done to
date, but I don't really know where to start. Can someone suggest a
place? Bugzilla? Seamonkey Wiki?
-- Stephen.
Philip Chee
> That's actually the problem for a lot of interesting extensions - there
> are workarounds/hackarounds that give good-looking results, but they're
> not OK to use in the official tree.
> Maybe we should have a list of officially-recommended extensions...
Well, as long as xSidebar is on that list.
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Sector Not Found (A)bort, (R)etry, (C)offee?
* TagZilla 0.059
Chris Thomas
> On Sat, 22 Jul 2006 12:44:02 -0500, Chris Thomas wrote:
>
>> That's actually the problem for a lot of interesting extensions - there
>> are workarounds/hackarounds that give good-looking results, but they're
>> not OK to use in the official tree.
>
>> Maybe we should have a list of officially-recommended extensions...
>
> Well, as long as xSidebar is on that list.
>
> Phil
In and of itself, it's not a big deal, but some of your ported Firefox
extensions may be.
Chris
Robert Kaiser
As it looks that moist people here agree with me, what about aligning us
once again with the (semi-)stable Geckos, which are following the
Firefox schedule: http://wiki.mozilla.org/Firefox2/Schedule
My proposal would be:
SeaMonkey 1.1 Alpha - Gecko 1.8.1b2: August 8th
SeaMonkey 1.1 Beta - Gecko 1.8.1rc1/2/3: September 1st/8th/15th
SeaMonkey 1.1 (final) - Gecko 1.8.1: September 26th
What do you think of that?
What RC should we base the Beta on?
Robert Kaiser
Philip Chee
> Philip Chee wrote:
>>> Maybe we should have a list of officially-recommended extensions...
>> Well, as long as xSidebar is on that list.
> In and of itself, it's not a big deal, but some of your ported Firefox
> extensions may be.
Just to clarify: I was joking here. I hope you didn't take me seriously!
(must remember to use smilies more often for the benefit of Americans in
this newsgroup)
Phil
--
Philip Chee <phi...@aleytys.pc.my>, <phili...@gmail.com>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
[ ]Why are elves chaotic? Brownian motion.
* TagZilla 0.059
Serge Gautherie
> As it looks that moist people here agree with me, what about aligning us
> once again with the (semi-)stable Geckos, which are following the
> Firefox schedule: http://wiki.mozilla.org/Firefox2/Schedule
>
> My proposal would be:
>
> SeaMonkey 1.1 Alpha - Gecko 1.8.1b2: August 8th
> SeaMonkey 1.1 Beta - Gecko 1.8.1rc1/2/3: September 1st/8th/15th
> SeaMonkey 1.1 (final) - Gecko 1.8.1: September 26th
>
> What do you think of that?
> What RC should we base the Beta on?
Fine.
I would suggest our beta on 1.8.1rc1,
with may be SeaMonkey rc too based on Gecko rc1 and/or rc2 ?
Robert Kaiser
> My proposal would be:
>
> SeaMonkey 1.1 Alpha - Gecko 1.8.1b2: August 8th
> SeaMonkey 1.1 Beta - Gecko 1.8.1rc1/2/3: September 1st/8th/15th
> SeaMonkey 1.1 (final) - Gecko 1.8.1: September 26th
>
> What do you think of that?
> What RC should we base the Beta on?
Unfortunately, no Council meber has given me an answer on that yet and
August 8th is nearing rapidly.
What should we do?
Robert Kaiser
Steve Wendt
>> SeaMonkey 1.1 Alpha - Gecko 1.8.1b2: August 8th
>
> Unfortunately, no Council meber has given me an answer on that yet and
> August 8th is nearing rapidly.
Looks like the Firefox schedule for 1.8.1b2 slipped a week, if that helps.
Andrew Schultz
Move forward. :)
At the very least, silence should be an indication that there aren't
major features that look likely to make it in time (or at least warrant
pushing back).
As far as important bugs go, the ones I know of have been nominated for
blocking status in bugzilla. A few have been granted blocking status,
but there are 14 left and it'd help to determine which ones should
actually block release before setting any schedule in stone.
--
Andrew Schultz
aj...@buffalo.edu
http://www.sens.buffalo.edu/~ajs42/
Robert Kaiser
> Looks like the Firefox schedule for 1.8.1b2 slipped a week, if that helps.
Probably it does help, yes... Where have you found that info?
Robert Kaiser
Pavel Cvrcek
> Probably it does help, yes... Where have you found that info?
http://wiki.mozilla.org/Firefox2/Schedule
http://www.google.com/calendar/embed?src=pdighgf028nmbjbrno8oed8vsg%40group.calendar.google.com
Regards,
--
Pavel Cvrcek
---------------------------------
e-mail: jasn...@jasnapaka.com
web: http://www.jasnapaka.com/
Matt Seitz
> The following questions need to be answered IMHO:
>
> 1) What has already landed on the 1.8 branch that makes current builds
> differ from 1.0 in a way that is worthwhile mentioning?
Here's the 1.1 features that lead me to use 1.1 instead of 1.0.x:
-Spell checking as you type
-Replying to a message I sent sets to the "To" field to the recipient of the
original message, rather than to setting it to my address.
-Linux version now detects a running process and simply opens a new window if
the "seamonkey" command is run again. Previously, it would keep trying to spawn
a new process, and then complain that the profile was already in use.
Mark Tyndall
> Robert Kaiser wrote:
>> The following questions need to be answered IMHO:
>>
>> 1) What has already landed on the 1.8 branch that makes current builds
>> differ from 1.0 in a way that is worthwhile mentioning?
>
> Here's the 1.1 features that lead me to use 1.1 instead of 1.0.x:
>
> -Spell checking as you type
WFM on 1.0.4 - oh, you mean in the browser. ;-)
[...snip...]
Looking at upcoming Tb2 Alpha nightlies, I like the new eye-candy - ie
the "new mail" info balloon (popped up from the system tray) and the
expanded tooltips when mousing over folders with new mail; hopefully
that's Core Mail/News rather than Tb-specific.
Saved searches seem to be much more robust (than in Tb1.5) as well.
regards,
Mark..
--
British English localisations of:
SeaMonkey <http://www.tyndall.org.uk/moz_en-gb.html>
Firefox <http://www.tyndall.org.uk/fb_en-gb.html>
Thunderbird <http://www.tyndall.org.uk/tb_en-gb.html>
Neil
> Looking at upcoming Tb2 Alpha nightlies, I like the new eye-candy - ie
> the "new mail" info balloon (popped up from the system tray) and the
> expanded tooltips when mousing over folders with new mail; hopefully
> that's Core Mail/News rather than Tb-specific.
Sorry, they're Tb-specific.
Robert Kaiser
> Robert Kaiser wrote:
>> What should we do?
>
> Move forward. :)
Yes, I think that will be a good idea...
> At the very least, silence should be an indication that there aren't
> major features that look likely to make it in time (or at least warrant
> pushing back).
I hope so...
> As far as important bugs go, the ones I know of have been nominated for
> blocking status in bugzilla. A few have been granted blocking status,
> but there are 14 left and it'd help to determine which ones should
> actually block release before setting any schedule in stone.
For reference, the queue is available at
https://bugzilla.mozilla.org/request.cgi?action=queue&type=blocking-seamonkey1.1a
We'll try to go through that ASAP.
The granted but not yet fixed-on-branch bugs can be found with
https://bugzilla.mozilla.org/buglist.cgi?keywords_type=nowords&keywords=fixed-seamonkey1.1a&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=blocking-seamonkey1.1a%2B
Everyone should concentrate on resolving those blockers as soon as we
can, or give us good arguments why they should not block the Alpha (or
Beta/Final?) after all...
Robert Kaiser
Andrew Schultz
> -Linux version now detects a running process and simply opens a new
> window if the "seamonkey" command is run again. Previously, it would
> keep trying to spawn a new process, and then complain that the profile
> was already in use.
This is already fixed on the branch for 1.1.
Robert Kaiser
> Matt Seitz wrote:
>> -Linux version now detects a running process and simply opens a new
>> window if the "seamonkey" command is run again. Previously, it would
>> keep trying to spawn a new process, and then complain that the profile
>> was already in use.
>
> This is already fixed on the branch for 1.1.
That why Mark was saying :)
Robert Kaiser
Robert Kaiser
> Mark Tyndall wrote:
>
>> Looking at upcoming Tb2 Alpha nightlies, I like the new eye-candy - ie
>> the "new mail" info balloon (popped up from the system tray) and the
>> expanded tooltips when mousing over folders with new mail; hopefully
>> that's Core Mail/News rather than Tb-specific.
>
> Sorry, they're Tb-specific.
Those tooltips are, the "new mail" info thingy is in SeaMonkey as well -
and I like it :)
Robert Kaiser
Robert Kaiser
> For reference, the queue is available at
> https://bugzilla.mozilla.org/request.cgi?action=queue&type=blocking-seamonkey1.1a
>
> https://bugzilla.mozilla.org/buglist.cgi?keywords_type=nowords&keywords=fixed-seamonkey1.1a&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=blocking-seamonkey1.1a%2B
I've gone through the list, and we have 3 requests open where I'm not
sure if they should block the Alpha, and then there's
https://bugzilla.mozilla.org/show_bug.cgi?id=332668 which might still
need some discussion, even if I've minused it for now. A fix would be
preferred to long discussions, as always :)
We additionally have have 4 open confirmed blockers which need to be
fixed ASAP so that we're able to release the Alpha at all!
Assignees, please, help us to get the release out by working on fixes;
others, please help us with testing so that we detect any other bugs
that need fixing.
Thanks,
Robert Kaiser
Neil
TB's "new mail" info no longer uses the standard alert service - they
roll their own...
Robert Kaiser
> My proposal would be:
>
> SeaMonkey 1.1 Alpha - Gecko 1.8.1b2: August 8th
> SeaMonkey 1.1 Beta - Gecko 1.8.1rc1/2/3: September 1st/8th/15th
> SeaMonkey 1.1 (final) - Gecko 1.8.1: September 26th
>
> What do you think of that?
> What RC should we base the Beta on?
>
> Robert Kaiser
Looks like the Gecko 1.8.1 releases slipped again, as posted in
m.d.planning (Message-ID:
<mailman.2193.1155189...@lists.mozilla.org>)
Beta 2 Code Freeze: August 16th, 11:59pm PDT
Beta 2 QA Cycle : August 17th through 22nd
Beta 2 Release : August 23rd
Looking at the progress of our blocker lists, we should manage to
release an Alpha an the new date easier - but now I hope we really will
make it.
We need to clear the following queues until then:
confirmed blockers:
https://bugzilla.mozilla.org/buglist.cgi?keywords_type=nowords&keywords=fixed-seamonkey1.1a&field0-0-0=flagtypes.name&type0-0-0=equals&value0-0-0=blocking-seamonkey1.1a%2B
blocking requests:
https://bugzilla.mozilla.org/request.cgi?action=queue&type=blocking-seamonkey1.1a
Robert Kaiser