Als you all probably know, we finally have released SeaMonkey 1.0 last night. I'd like to thanks everyone who worked on getting this done, i.e. all other SeaMonkey Council members, but also everyone who has filed bugs, wrote up patches, (super)reviewed them, used or even smoketested the build that led up to this release.
This is also the time to look ahead on what's to come next though: (All the plans below are not 100% set in stone, we're happy if you contribute to the discussion in this thread by proposing evolvement of them.)
First of all, we are planning to keep up with any Gecko security patches and do further 1.0.x releases based on the 1.8.0 branch with practically the same agenda as mozilla.org drivers have for FF/TB 1.5.0.x - we should probably make up a page that lists vulnerabilities and their fixes though, just like the other products have (even if most of the stuff will probably just be copied from there).
The real development work will go on elsewhere though:
SeaMonkey 1.1 is planned to come off the 1.8 branch, with some feature work but no fundamental changes to our infrastructure. See the tracking bug for more details what we plan to land there: <https://bugzilla.mozilla.org/show_bug.cgi?id=315312> All patches to SeaMonkey-specific code on this branch need approval from a SeaMonkey Council member. Just like with Gecko on this branch, the policy is to not break those APIs that SeaMonkey 1.0 provides, make it easy for extension authors to support 1.1, ideally enable people to just run the 1.0 extensions on 1.1 as well (of course, that might depend on what stuff they're using). The general target for 1.1 is making SeaMonkey a better experience without tearing apart its internals.
Contrary to that, the trunk is the target of some pretty big stuff. On one hand, that does of course mean Gecko shifting to a cairo-based backend (which will drop support for Windows systems older than Win2k and Microsoft compilers older than VC7, by the way - it's unsure to which extent Linux GTK1 support can/will be retained). On the other hand, this also means some heavy shifting on the SeaMonjkey side of things, most importantly: - step-by-step transition to toolkit (at least the widgets, hopefully parts or all of the infrastructure as well) - source L10n - and consolidation of our suite-specific code in the suite/ directory of the mozilla.org tree.
I'd like everyone listening here to contribute to those plans with discussion in this group, and the wiki doc should get updated accordingly when that discussion results in more concrete steps. We'd like to keep our application in a basically working shape during the transition, though some breakage of certain parts may be allowed intermediately.
Now that we have 1.0 out the door, I hope we can really start on working on this stuff very soon.
BTW, I hope the mozilla.org build team will be able to continue providing trunk tinderboxen for SeaMonkey (which might need some updating in the light of the cairo work etc.), I'll continue to cover the branches with my own tinderboxen (a Mac box should join that group very soon now).
> Hmm, am I the only one who likes SeaMonkey's "wallet" function over > Firefoxes "satchel"? Also with its override function... Do the items > mean that you want to port wallet to Toolkit or want to port SeaMonkey > to use satchel?
I'd have no intention of keeping wallet, esp. as from what I know, the code is basically abandoned and not something that people want to stick their fingers in, I might even be badly written.
We can look into improving satchel though (if there are good reasons, toolkit people are happily taking improvements to their code), what problems do you see with it?
> Regarding the transition of chrome files, wasn't it said somewhere some > months ago that it might be a good idea to pre-process away the license > header before packing it into the JAR files? I seem to remember that > somebody had done that and measured some difference in startup and > page-load speed. If that is done, this transition might be a good point > to do that.
Actually, I've always been one of the biggest offenders of that, and it's no important step in this transition for sure, as it's just a nit and (if wanted) easy to do (in the current as well as the future directory layout and build systems).
> I'd like everyone listening here to contribute to those plans with > discussion in this group, and the wiki doc should get updated > accordingly when that discussion results in more concrete steps. We'd > like to keep our application in a basically working shape during the > transition, though some breakage of certain parts may be allowed > intermediately.
Any help I can lend, please don't hesitate to cc me on bugs or (if no one's working on them) assign to me. Fixing bugs in XBL bindings is fun for me, and synch work is very important.
Rich Gray wrote: > Somehow, the cut operation picked up the version too old message. > Is there a ticking time bomb here? In 4 weeks, will 1.0 users > start getting this?? Is being able to cut invisible text a bug??
Known deal with display:none content. The problem is that it's not clear what should really be copied in such cases, esp. since copying operates on the DOM tree.
>> We can look into improving satchel though (if there are good reasons, >> toolkit people are happily taking improvements to their code), what >> problems do you see with it?
> AFAIK satchel does not prefill forms automatically, but one has to start > typing in something first. And as I said, satchel does not have an > equivalent to wallet.crypto.autocompleteoverride (I remember that it > wasn't allowed to get something similar).
We should probably look into that. maybe we can find some solution that works well for us, maybe also integrates such functionality if needed, but still base on satchel. We'll see once we get to a stage where that migration will happen. If you got the time and dev skills, we'd be happy if you'd look into that ;-)
>>> Regarding the transition of chrome files, wasn't it said somewhere some >>> months ago that it might be a good idea to pre-process away the license >>> header before packing it into the JAR files? >> Actually, I've always been one of the biggest offenders of that
> Why? If it improves speed and download size?
It's completely against my understanding of what per-file licenses are for.
>> I'd like everyone listening here to contribute to those plans with >> discussion in this group, and the wiki doc should get updated >> accordingly when that discussion results in more concrete steps. We'd >> like to keep our application in a basically working shape during the >> transition, though some breakage of certain parts may be allowed >> intermediately.
> Any help I can lend, please don't hesitate to cc me on bugs or (if no > one's working on them) assign to me. Fixing bugs in XBL bindings is fun > for me, and synch work is very important.
What we'd need now are concrete plans, and step-by-step list of what we're doing, so that people can hook into that and say "OK, I'll do step/file X". We'd be happy about everyone contributing to that plan, the current wiki doc is quite rough still.
Anyways, thanks for your help, we'll get back to you on that for sure! ;-)
Peter Weilbacher wrote: > [... about stripping license headers from chrome files...] >> It's completely against my understanding of what per-file licenses are for.
> In a sense, they are stripped from C/C++ sources, too, a user does not > usually need to look at them and hence does not need to download them. > But I am beginning to see your point as in principle one can unpack them > from the JARs.
The licenses are the licenses for the source code. The fact that xul/js is interpreted code doesn't mean that the installed chrome files are "source-code". For correctness the licenses should be removed because a binary build need not to be a triple-licensed build and therefore the licenses are wrong for a binary distribution. But IANAL!
Wolfgang Rosenauer wrote: > Peter Weilbacher wrote:
>>[... about stripping license headers from chrome files...]
>>>It's completely against my understanding of what per-file licenses are for. > The licenses are the licenses for the source code. > The fact that xul/js is interpreted code doesn't mean that the installed > chrome files are "source-code". For correctness the licenses should be > removed because a binary build need not to be a triple-licensed build > and therefore the licenses are wrong for a binary distribution. > But IANAL!
Well at least, to save our collective backs, and everyone who wants SM to thrive, the council would best be having some lawyers peek in on "this" before it was done.
And the concept would also be useful for All "Aviary" apps anyway.
Wolfgang Rosenauer wrote: > Peter Weilbacher wrote: >> [... about stripping license headers from chrome files...] >>> It's completely against my understanding of what per-file licenses are for. >> In a sense, they are stripped from C/C++ sources, too, a user does not >> usually need to look at them and hence does not need to download them. >> But I am beginning to see your point as in principle one can unpack them >> from the JARs.
> The licenses are the licenses for the source code. > The fact that xul/js is interpreted code doesn't mean that the installed > chrome files are "source-code". For correctness the licenses should be > removed because a binary build need not to be a triple-licensed build > and therefore the licenses are wrong for a binary distribution. > But IANAL!
> Wolfgang
X-Post to mozilla.legal. Just to get Gerv's comment maybe?
Wolfgang Rosenauer wrote: > Wolfgang Rosenauer wrote: >> Peter Weilbacher wrote: >>> [... about stripping license headers from chrome files...] >>>> It's completely against my understanding of what per-file licenses are for. >>> In a sense, they are stripped from C/C++ sources, too, a user does not >>> usually need to look at them and hence does not need to download them. >>> But I am beginning to see your point as in principle one can unpack them >>> from the JARs. >> The licenses are the licenses for the source code. >> The fact that xul/js is interpreted code doesn't mean that the installed >> chrome files are "source-code". For correctness the licenses should be >> removed because a binary build need not to be a triple-licensed build >> and therefore the licenses are wrong for a binary distribution. >> But IANAL!
>> Wolfgang
> X-Post to mozilla.legal. Just to get Gerv's comment maybe?
The installed chrome files are not considered by us to be source code in the MPL sense. However, the licence headers are not, as such, wrong - if you took one of those files and removed it from the distribution, you could use it under one of those three licences.
So the licences could be removed, but do not have to be. Is this a space-saving issue? I would hope that the ZIP algorithm on the JARs would mean it doesn't make much difference. However, if you still want to remove them, the LICENSE BLOCK headers were put there for just this purpose. If you remove all text up to (but not including) those lines, the idea is that any multi-line comments will still be intact and nothing will break.
(Ideally, it would be possible to remove those lines also, and remove the entire comment block. But I don't know if every block exactly conforms to the template in the correct way. Try it and see.)
Gervase Markham wrote: > So the licences could be removed, but do not have to be. Is this a > space-saving issue? I would hope that the ZIP algorithm on the JARs > would mean it doesn't make much difference.
Wolfgang Rosenauer wrote: > Peter Weilbacher wrote: >> [... about stripping license headers from chrome files...] >>> It's completely against my understanding of what per-file licenses are for.
>> In a sense, they are stripped from C/C++ sources, too, a user does not >> usually need to look at them and hence does not need to download them. >> But I am beginning to see your point as in principle one can unpack them >> from the JARs.
> The licenses are the licenses for the source code.
I have done part of the experiment, and removed the license blocks from the JAR files of my current SeaMonkey build [Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20060127 SeaMonkey/1.1a].
To summarize: while the timing measurements should perhaps be repeated on a machine that does nothing else, and then supplemented with page-load and window open tests, only the on disk size would validate the removal of the license header.
Christian Biesinger wrote: > Gervase Markham wrote:
>> So the licences could be removed, but do not have to be. Is this a >> space-saving issue? I would hope that the ZIP algorithm on the JARs >> would mean it doesn't make much difference.
> The .jar files are not compressed...
Although the .xpi files in which they are downloaded are...
> To summarize: while the timing measurements should perhaps be repeated > on a machine that does nothing else, and then supplemented with > page-load and window open tests, only the on disk size would validate > the removal of the license header.
Well, and on-disk size is really cheap and non-problematic these days (forget embedded systems here, as those want minimo or such anyways, and not SeaMonkey).
I wonder though that zip is that weak in compression that it still saves 5% there - Though 133K don't matter much compared to the full SeaMonkey download size. A transition to 7zip for the Windows installer would save us much more than that stripping of license headers ;-)
And with no impact on performance and bloat, the question is if preprocessing every single chrome file is worth it...
Robert Kaiser wrote: > Peter Weilbacher schrieb: >> To summarize: while the timing measurements should perhaps be repeated >> on a machine that does nothing else, and then supplemented with >> page-load and window open tests, only the on disk size would validate >> the removal of the license header.
> Well, and on-disk size is really cheap and non-problematic these days > (forget embedded systems here, as those want minimo or such anyways, and > not SeaMonkey).
> I wonder though that zip is that weak in compression that it still saves > 5% there - Though 133K don't matter much compared to the full SeaMonkey > download size. > A transition to 7zip for the Windows installer would save us much more > than that stripping of license headers ;-)
> And with no impact on performance and bloat, the question is if > preprocessing every single chrome file is worth it...
> Robert Kaiser
Do a "make realchrome" in xpfe/global and the toolkit equivalent - toolkit's takes SIGNIFICANTLY longer to build. Assuming it's because of the preprocessing, I'd argue against it since it would slow down the type of partial-rebuild I do most often when hacking.
Peter Weilbacher aber hob zu reden an und schrieb:
> To summarize: while the timing measurements should perhaps be repeated > on a machine that does nothing else, and then supplemented with > page-load and window open tests, only the on disk size would validate > the removal of the license header.
I don't think that disk space savings of ~2MB are worth removing the licence headers.
>> And with no impact on performance and bloat, the question is if >> preprocessing every single chrome file is worth it...
> Do a "make realchrome" in xpfe/global and the toolkit equivalent - > toolkit's takes SIGNIFICANTLY longer to build. Assuming it's because > of the preprocessing, I'd argue against it since it would slow down > the type of partial-rebuild I do most often when hacking.
Hah, I can beat that - on linux, with --enable-chrome-format=symlink I hardly have to rebuild chrome at all, and with the xul cache, I only have to restart for .properties file changes too :-)
>>> And with no impact on performance and bloat, the question is if >>> preprocessing every single chrome file is worth it...
>> Do a "make realchrome" in xpfe/global and the toolkit equivalent - >> toolkit's takes SIGNIFICANTLY longer to build. Assuming it's because >> of the preprocessing, I'd argue against it since it would slow down >> the type of partial-rebuild I do most often when hacking.
> Hah, I can beat that - on linux, with --enable-chrome-format=symlink I > hardly have to rebuild chrome at all, and with the xul cache, I only > have to restart for .properties file changes too :-)
With mentioning the xul cache, I wonder if Peter's test disabled it. I also wonder if anyone is willing to try this on a nearly dedicated machine, so we can get more accurate results.
Justin Wood (Callek) wrote: > With mentioning the xul cache, I wonder if Peter's test disabled it. I > also wonder if anyone is willing to try this on a nearly dedicated > machine, so we can get more accurate results.
Well, if the difference is sufficiently small that it can't be noticed in 24 startups, it's probably too small to be useful (whatever the precise difference is).
Perhaps a more important is how the startup times were measured (Peter omitted that from his post). Assuming the tests Peter ran were performed consecutively, there would probably be a bigger difference testing cold starts.
Peter Weilbacher wrote: > Yes, consecutive starts, measured with the startup-unix.pl script from > the CVS tree. I was measuring on Linux and didn't have time enough to > think of a way to trash the disk cache buffers between every try.
cat `find /foo/bar/hugedirectory -type f` > /dev/null should work :)
