Bug 285696 (suite-rebranding)

Check in code for rebranding Mozilla for milestone releases

RESOLVED FIXED

Status

SeaMonkey
General
--
major
RESOLVED FIXED
14 years ago
7 years ago

People

(Reporter: WeirdAl, Assigned: Robert Kaiser)

Tracking

(Depends on: 1 bug)

Dependency tree / graph
Bug Flags:
blocking-seamonkey1.0a +

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 3 obsolete attachments)

23.55 KB, patch
Robert Kaiser
: review+
Robert Kaiser
: superreview+
Details | Diff | Splinter Review
2.50 KB, patch
Robert Kaiser
: review+
neil@parkwaycc.co.uk
: superreview+
Details | Diff | Splinter Review
5.16 KB, patch
Biesinger
: review+
neil@parkwaycc.co.uk
: superreview+
Details | Diff | Splinter Review
5.46 KB, patch
Biesinger
: review+
neil@parkwaycc.co.uk
: superreview+
Details | Diff | Splinter Review
223.26 KB, patch
neil@parkwaycc.co.uk
: review+
neil@parkwaycc.co.uk
: superreview+
Benjamin Smedberg
: approval1.8b3+
Details | Diff | Splinter Review
(Reporter)

Description

14 years ago
Per the community agreement with the Mozilla Foundation, we (the community) will
be required to rebrand the Mozilla Application Suite for every release we make.
 We first need to identify all the places where such branding takes place
(splash screen, brand.dtd/properties, etc.).

After that (and once we have a confirmed name), we should start work (preferably
through the wiki so as to avoid extra bug attachments) on the various pieces of
art.  Similarly, we should start writing patches so that the rebranding can be
turned on by adding a single option to standard .mozconfig files (either a
./seamonkey/config/.mozconfig like file or a --enable-brand=seamonkey, or
something like that).
(Reporter)

Updated

14 years ago
Assignee: kairo → general
(Reporter)

Updated

14 years ago
Assignee: general → kairo
well, given that mf really has no interest in trunk seamonkey, why not just
change the branding stuff directly, without a configure option?
(Assignee)

Comment 2

14 years ago
Correct. If we don't need some trademark rules similar to what Firefox and
Thunderbird have, we don't need all those compiling switches, we just can check
in our new branding strings and artwork and be done with it.

In any case, this bug will cover whatever we have to do to get our new branding
in, either along with those build system things or not. We'll see that when the
name and trademark stories clear up.
(Assignee)

Updated

14 years ago
Alias: suite-rebranding
As expected, changing brand.dtd and .properties does not suffice. (Note: given
how it is used, it seems ok to change vendorShortName to "Seamonkey" as well)

NSS hardcodes "Mozilla": /security/nss/lib/ckfw/builtins/certdata.c, line 591 --
{ (void *)"Mozilla Builtin Roots", (PRUint32)22 }
that should probably be changed to "mozilla.org" or something

Installer hardcodes Mozilla in various places

So do environment variables, but we can probably ignore that, I think

/xpfe/bootstrap/nsAppRunner.cpp, line 154 -- #define MOZ_APP_NAME "mozilla"
and other places in this file will need to be patched


There'll be other things too... this is just what I saw at first sight.

Updated

14 years ago
Blocks: 286066
Asa, would it be reasonable to release future 1.8 betas under the community
branding?
(Assignee)

Comment 5

14 years ago
*** Bug 286065 has been marked as a duplicate of this bug. ***

Comment 6

14 years ago
Reminder: Please remember to keep out the Godzilla-like images and/or wording
from this SeaMonkey build as to avoid the intellectual property information
(trademark) conflict and licensing issues as we had in the past.
(Assignee)

Comment 7

14 years ago
We should look into help as well when rebranding. Ideally, we have a correct
patch for bug 232794 landed before, but else we need to s/Mozilla/whatever there.

Comment 8

14 years ago
(In reply to comment #7)
> We should look into help as well when rebranding. Ideally, we have a correct
> patch for bug 232794 landed before, but else we need to s/Mozilla/whatever there.

"Mozilla" shouldn't be a problem to change without the patch, it's already an
entity (&brandShortName;). Of course we will then end up with "xxx mail &
Newsgroups" etc.

(Assignee)

Comment 9

14 years ago
Reminder for myself: check MailNews start page (including remove of standalone
tip), look through (X)HTML files living in locale/
(Assignee)

Comment 10

14 years ago
I've started preparing a patch but I'll wait for legal clearance on the name
before posting it.

Some notes about things that I still have not in my patch:

We should also update the release notes URL in those two files:
mozilla/xpfe/global/resources/locale/en-US/region.dtd
mozilla/xpfe/global/resources/locale/en-US/builtinURLs.rdf

and the default startup page in
mozilla/xpfe/browser/resources/locale/en-US/region.properties

I've not yet touched those files noted in comments here:
mozilla/security/nss/lib/ckfw/builtins/certdata.c
Installer (can someone tell me file names here?)
locale (X)HTML files
(Assignee)

Updated

14 years ago
Depends on: 287687
(Assignee)

Comment 11

14 years ago
Locale files that still contain a harcdoded "Mozilla"-Reference that should be
changed (no paths given at the moment, I'm retriveing data from L10n tool):
HtmlForm.properties (DefaultFormSubject)
filter.properties (cannotEnableFilter)
messenger.properties (filterFolderTruncateFailed)
(Assignee)

Updated

14 years ago
Depends on: 287689
(Assignee)

Comment 12

14 years ago
additionally, I found those:
communicator/search/default.htm
help/mozillahelp.rdf
help/help-toc.rdf
help/help-index1.rdf (?)

...and I still trusted the help XHTML files to have only hits because of the
copyright line...
(Assignee)

Updated

14 years ago
Depends on: 287695
(Assignee)

Comment 13

14 years ago
As I can't give you the patch yet, here's a list of files I'm touching right now:
mozilla/configure.in
mozilla/editor/ui/locales/en-US/chrome/region/region.properties
mozilla/extensions/help/resources/locale/en-US/mozillahelp.rdf
mozilla/extensions/help/resources/locale/en-US/help-toc.rdf
mozilla/mailnews/base/search/resources/locale/en-US/filter.properties
mozilla/mailnews/base/resources/content/start.xhtml
mozilla/mailnews/base/resources/locale/en-US/messenger.properties
mozilla/mailnews/base/resources/locale/en-US/region.properties
mozilla/mailnews/base/resources/locale/en-US/start.dtd
mozilla/profile/defaults/bookmarks.html
mozilla/xpfe/bootstrap/nsAppRunner.cpp
mozilla/xpfe/bootstrap/version.txt
mozilla/xpfe/bootstrap/browser-prefs.js
mozilla/xpfe/bootstrap/Makefile.in
mozilla/xpfe/browser/resources/locale/en-US/region.properties
mozilla/xpfe/communicator/resources/locale/en-US/brand.dtd
mozilla/xpfe/communicator/resources/locale/en-US/brand.properties
mozilla/xpfe/components/search/resources/locale/en-US/default.htm
mozilla/xpfe/global/resources/content/version.dtd
mozilla/xpfe/global/Makefile.in
mozilla/xpfe/global/resources/content/about.xhtml

What I haven't checked yet:
Installer (can someone tell me file names here?)

I haven't touched start page or release notes, see comment #10
I included a fix for the UA string though, so bug 286057 also gets fixed.

What I won't touch:
mozilla/security/nss/lib/ckfw/builtins/certdata.c
HtmlForm.properties (see bug 287695)

I also won't reach into Venkman, ChatZilla or Calendar (yet), though I've filed
bugs for their hardcoded strings. If you wonder, inspector has no hardcoded
"Mozilla" in the files I checked. Woo-hoo!

Comment 14

14 years ago
It's been some time since I was in that area of the code, but I can give you a
partial list of Installer files.

There may be additional ones.

mozilla/xpinstall/packages-static-win
mozilla/xpinstall/packages-unix
mozilla/xpinstall/packages-win
mozilla/xpinstall/packager/build/cfgs/mozilla.pl
mozilla/xpinstall/packager/build/scripts/makecfgini.pl
mozilla/xpinstall/packager/build/scripts/makeuninstallini.pl
mozilla/xpinstall/packager/build/win/mozilla/defaults_info.ini
mozilla/xpinstall/packager/unix/makecfgini.pl
mozilla/xpinstall/packager/win_gre/config.it
mozilla/xpinstall/packager/win_gre/makecfgini.pl
mozilla/xpinstall/packager/win_gre/makeuninstallini.pl
mozilla/xpinstall/packager/win_gre/uninstall.it
mozilla/xpinstall/packager/windows/defaults_info.ini
mozilla/xpinstall/packager/windows/makeall.pl
mozilla/xpinstall/packager/windows/makecfgini.pl
mozilla/xpinstall/packager/windows/makeuninstallini.pl
mozilla/xpinstall/wizard/windows/builder/build.pl
mozilla/xpinstall/wizard/windows/builder/build_gre.pl
mozilla/xpinstall/wizard/windows/builder/build_mfcembed.pl
mozilla/xpinstall/wizard/windows/builder/build_static.pl

Updated

14 years ago
Depends on: 287713

Comment 15

14 years ago
Does it make sense to start looking at replacing the Netscape stuff at the same
time?
(Assignee)

Comment 16

14 years ago
(In reply to comment #15)
> Does it make sense to start looking at replacing the Netscape stuff at the same
> time?

If you find Netscape stuff that has to be replaced, maybe... I doubt there's any
left though (and referring to e.g Netscape 4.x migration is OK, just to remind
you)...
(Assignee)

Updated

14 years ago
Flags: blocking-seamonkey1.0a+

Comment 17

14 years ago
The following files might need some work too:
/xpfe/bootstrap/nsNativeAppSupportBeOS.cpp
/xpfe/bootstrap/nsNativeAppSupportOS2.cpp
/xpfe/bootstrap/nsNativeAppSupportWin.cpp

Updated

14 years ago
Depends on: 287943

Updated

14 years ago
Depends on: 287944

Updated

14 years ago
Depends on: 287945
(Assignee)

Comment 18

14 years ago
Created attachment 178797 [details] [diff] [review]
patch stage 1: clean up some stuff and use MOZ_APP_* more often

OK, I got a first stage of the patch for you. This doesn't contain any real
branding change, but lots of stuff that makes the real rebranding easier.

And yes, it contains two small other things:
- Remove the "advertising" for Thunderbird from mailnews start page
- use correct URL for branding bundle in about.xhtml
Attachment #178797 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #178797 - Flags: review?(cbiesinger)
Comment on attachment 178797 [details] [diff] [review]
patch stage 1: clean up some stuff and use MOZ_APP_* more often

+cannotEnableFilter=This filter was probably created by future version of this
software. You cannot enable this filter because we don't know how to apply it.

hm, ok. maybe the real name would be better here...

mozilla/xpfe/bootstrap/mozilla.man.in
+Print \fB/usr/bin/@MOZ_APP_NAME@-bin\fR version.

this is still wrong if $prefix != /usr... stuff below uses @bindir@, why not
use it here too?


Please don't check that GARBAGE line in xpfe/bootstrap/Makefile.in in with this
patch. I would prefer if rules.mk or somesuch handled it automatically.

nsAppRunner.cpp:
+  printf("%s %s, Copyright (c) 2003-2005 mozilla.org", MOZ_APP_DISPLAYNAME,
MOZ_APP_VERSION);

might be nice to also output the gecko version

mozilla/xpfe/bootstrap/macbuild/Contents/Info.plist.in

please get a mac person to review these changes, esp. CFBundleIdentifier


Now that about.xhtml no longer lives in /locale/, version.dtd can probably go
away; unless we want it for other reasons as well

r=biesi with at least the manpage change and removal of the GARBAGE line, and
review of Info.plist by a mac person
Attachment #178797 - Flags: review?(cbiesinger) → review+

Comment 20

14 years ago
Comment on attachment 178797 [details] [diff] [review]
patch stage 1: clean up some stuff and use MOZ_APP_* more often

Please fix up the grammar of cannotEnableFilter to say "by a future version".
Are those DEFINES supposed to be on separate lines?
Would you mind changing the bug reporting address to https: please?
You don't have to use %s to embed string contents in printf format strings, you
could use "literal" LITERAL concatenation (although I don't know what other
modules do).
Feel free to fix up the broken build id code.
Do we want to display the Gecko version in about: ? Former Suite users might
want to know ;-)
Attachment #178797 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+

Comment 21

14 years ago
(In reply to comment #20)
> Do we want to display the Gecko version in about: ? Former Suite users might
> want to know ;-)

Isn't the Gecko version the "rv" part of the Browser line?  The "rv" part is
there in both Mozilla and Firefox:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050319
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6) Gecko/20050225 Firefox/1.0.1

Will the "rv" part be removed in the new suite?  I guessed that the browser line
would just be something like

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/YYYYMMDD SomeSecretName/1.0

(i.e. with the only change being that the name and version number are added at
the end of the line)

The browser line is included on the about: page, so would it really be necessary
to mention the Gecko version elsewhere too?

Comment 22

14 years ago
r=sfraser on the mac parts of the patch.
(Assignee)

Comment 23

14 years ago
(In reply to comment #19)
> hm, ok. maybe the real name would be better here...

For one thing, this is a rarely shown text (only when we change the filter
interface and an older version tries to use it again), for the other, if we
would be correct there, we'd need to list all possible product names that thise
future version can have, and I decided extending it to even
"SeaMonkey/Thunderbird/Mozilla/Netscape" would look very strange to a user.

> mozilla/xpfe/bootstrap/mozilla.man.in
> +Print \fB/usr/bin/@MOZ_APP_NAME@-bin\fR version.
> 
> this is still wrong if $prefix != /usr... stuff below uses @bindir@, why not
> use it here too?

I think the stuff below might be wrong in case of prefix things as well, but I
updated it to use the same path for @MOZ_APP_NAME@-bin as below. good catch :)

> Please don't check that GARBAGE line in xpfe/bootstrap/Makefile.in in with this
> patch. I would prefer if rules.mk or somesuch handled it automatically.

OK, I'll exclude it for now and talk to bsmedberg if we really need it.

> nsAppRunner.cpp:
> +  printf("%s %s, Copyright (c) 2003-2005 mozilla.org", MOZ_APP_DISPLAYNAME,
> MOZ_APP_VERSION);
> 
> might be nice to also output the gecko version

We can probably add that later, if wanted. It should be easy.

> mozilla/xpfe/bootstrap/macbuild/Contents/Info.plist.in
> 
> please get a mac person to review these changes, esp. CFBundleIdentifier

OK, I hope to find one...

> Now that about.xhtml no longer lives in /locale/, version.dtd can probably go
> away; unless we want it for other reasons as well

Hmm, good idea, I'll look into that in stage 2 (so that I can do some testing
before it lands)

(In reply to comment #20)
> Please fix up the grammar of cannotEnableFilter to say "by a future version".

Done.

> Are those DEFINES supposed to be on separate lines?

Should I better only write the "DEFINES +=" once and use \ at the line endings
to concatenate them all at once? I think I can't stick them into one line
anyways without breaking the 80-character barrier...

> Would you mind changing the bug reporting address to https: please?

Sure. Done.

> You don't have to use %s to embed string contents in printf format strings, you
> could use "literal" LITERAL concatenation (although I don't know what other
> modules do).

Well, I just used the style of nsAppRunner.cpp - as I'm not really experienced
with C++ (yet), I'd gladly use any other style if someone shows me how to do it ;-)

> Feel free to fix up the broken build id code.

Sure. Where? How? Well, perhaps I might really look into this later, when all
that rebranding stuff is done... :)

> Do we want to display the Gecko version in about: ? Former Suite users might
> want to know ;-)

Well, we display the full UA string, which contains the Gecko version. Is that
enough? Should we make it more visible? In which way?
(Assignee)

Comment 24

14 years ago
Created attachment 178870 [details] [diff] [review]
patch stage 1, review nits fixed (checked in)

OK, this is the stage 1 patch with the review nits fixed.
I still need input if it builds OK on windows and mac before I check it in
though (linux was tested by me and doron).
(Assignee)

Updated

14 years ago
Attachment #178797 - Attachment is obsolete: true
Attachment #178870 - Flags: superreview+
Attachment #178870 - Flags: review+
(In reply to comment #23)
> we'd need to list all possible product names that thise
> future version can have, and I decided extending it to even
> "SeaMonkey/Thunderbird/Mozilla/Netscape" would look very strange to a user.

Well, just using brandShortName should be ok, and is what I meant... But that
may be hardish to implement.
 
> > You don't have to use %s to embed string contents in printf format strings, you
> > could use "literal" LITERAL concatenation (although I don't know what other
> > modules do).

neil: I'm realizing that apprunner seems to already use %s for HELP_SPACER_n,
which is also a #define...
(Reporter)

Comment 26

14 years ago
(In reply to comment #24)
> OK, this is the stage 1 patch with the review nits fixed.
> I still need input if it builds OK on windows and mac before I check it in
> though (linux was tested by me and doron).

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050328
It compiles just fine.

Comment 27

14 years ago
(In reply to comment #24)
>I still need input if it builds OK on windows
It built under mingw using make -s -C objdir/mailnews realchrome && make -s -C
objdir/xpfe/bootstrap libs && make -s -C objdir/xpfe/global realchrome
works fine on windows xp, msvc.net. mozilla -version and help/about mozilla look
right.
(Assignee)

Updated

14 years ago
Depends on: 288192
(Assignee)

Updated

14 years ago
Depends on: 288199
Comment on attachment 178870 [details] [diff] [review]
patch stage 1, review nits fixed (checked in)

applied this patch to 2005-03-28 CVS code and it builds and runs fine on Mac 
OS X.
(Assignee)

Comment 30

14 years ago
Comment on attachment 178870 [details] [diff] [review]
patch stage 1, review nits fixed (checked in)

OK, stage 1 is checked in, let's move forward!
Attachment #178870 - Attachment description: patch stage 1, review nits fixed → patch stage 1, review nits fixed (checked in)
(Assignee)

Updated

14 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

14 years ago
Depends on: 288690

Comment 31

14 years ago
Shouldn't https://bugzilla.mozilla.org/show_bug.cgi?id=244672 (and possibly also
https://bugzilla.mozilla.org/show_bug.cgi?id=243575) be added to the list of
bugs this depends on?
(Assignee)

Comment 32

14 years ago
The name of our application does not affect bug 243575, our rebranding is
independent from that one. Bug 244672 is a good point and would be nice to have
in that effort, but we won't block the alpha for it (same with a bunch of other
dependencies though)...
Depends on: 244672
Created attachment 179393 [details] [diff] [review]
Fix Man Page

As discussed with Kairo earlier today, this patch fixes the manual page found
in mozilla/xpfe/bootstrap that was broken by the stage 1 patch - basically some
variables weren't being replaced, and the paths were wrong so we've set them to
the default unix installation paths for now.
Attachment #179393 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #179393 - Flags: review?(kairo)
(Assignee)

Comment 34

14 years ago
Comment on attachment 179393 [details] [diff] [review]
Fix Man Page

r- via IRC. We should better use the configured prefix (mozappdir) that we
install to with "make install". That way some distro can use standard configure
options and get a correct man file (I hope).
Attachment #179393 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #179393 - Flags: review?(kairo)
Attachment #179393 - Flags: review-
Created attachment 179410 [details] [diff] [review]
Revised fix for Man Page

Revised patch to use mozappdir.
Attachment #179393 - Attachment is obsolete: true
Attachment #179410 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #179410 - Flags: review?(kairo)
(Assignee)

Comment 36

14 years ago
Comment on attachment 179410 [details] [diff] [review]
Revised fix for Man Page

Yes, looks good to me this way.
Attachment #179410 - Flags: review?(kairo) → review+
Comment on attachment 179410 [details] [diff] [review]
Revised fix for Man Page

Sorry folks, I got this wrong again, make install installs the wrapper script
into bindir & the executable into mozappdir.
New patch coming.
Attachment #179410 - Attachment is obsolete: true
Attachment #179410 - Flags: superreview?(neil.parkwaycc.co.uk)
Created attachment 179417 [details] [diff] [review]
Revised fixed for man page 2 (checked in)

Ok, this one matches where things go when we do a make install.
Attachment #179417 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #179417 - Flags: review?(kairo)
(Assignee)

Comment 39

14 years ago
Comment on attachment 179417 [details] [diff] [review]
Revised fixed for man page 2 (checked in)

OK, this seems to be where builds really go to for "make install" (and I guess
that's what most distributors do to create their packages)
Attachment #179417 - Flags: review?(kairo) → review+

Updated

14 years ago
Attachment #179417 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
(Assignee)

Comment 40

14 years ago
Comment on attachment 179417 [details] [diff] [review]
Revised fixed for man page 2 (checked in)

Manpage fix checked in.
Attachment #179417 - Attachment description: Revised fixed for man page 2 → Revised fixed for man page 2 (checked in)
(Assignee)

Comment 41

14 years ago
Created attachment 180057 [details] [diff] [review]
stage 1, additional fix 1: remove quoting trickery in bootstrap (checked in)

Looking through the recently checked in patch for bug 274928 and applying that
approach to our stuff, I realised we have to get rid of the \"$(MOZ_APP_NAME)\"
trickery in bootstrap's Makefile.in and instead use NS_STRINGIFY() in the .cpp,
just like dbaron did there, so we can stuff those strings into the UA without
problems (see bug 286057).
This patch does exactly that.
(Assignee)

Updated

14 years ago
Attachment #180057 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #180057 - Flags: review?(cbiesinger)
(Assignee)

Comment 42

14 years ago
Created attachment 180058 [details] [diff] [review]
stage 1, additional fix 2: remove version.dtd (checked in)

As biesi has requested it in his review nits for stage 1, and we still have to
wait for a complete solution, I hacked up the removal of version.dtd and
preprocessing of about.xhtml instead.
(Assignee)

Updated

14 years ago
Attachment #180058 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #180058 - Flags: review?(cbiesinger)

Updated

14 years ago
Attachment #180057 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+

Updated

14 years ago
Attachment #180058 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Attachment #180057 - Flags: review?(cbiesinger) → review+
Attachment #180058 - Flags: review?(cbiesinger) → review+

Comment 43

14 years ago
How does MOZ_APP_DISPLAYNAME work with different forms of the name in different
languages?  For example, assume the following two MOZ_APP_DISPLAYNAMEs:

Mozilla: Swedish genitive = Mozillas (i.e. an 's' is added)
Firefox: Swedish genitive = Firefox' (i.e. an apostrophe is added)

More complex modifications are likely to be needed in languages with more forms
of names.
(Assignee)

Comment 44

14 years ago
Comment on attachment 180057 [details] [diff] [review]
stage 1, additional fix 1: remove quoting trickery in bootstrap (checked in)

requesting approval: seamonkey-only fix so that we can use the new vendor
additions for UA
Attachment #180057 - Flags: approval1.8b2?
(Assignee)

Comment 45

14 years ago
Comment on attachment 180058 [details] [diff] [review]
stage 1, additional fix 2: remove version.dtd (checked in)

requesting approval: seamonkey-only cleanup of about page code
Attachment #180058 - Flags: approval1.8b2?
(Assignee)

Comment 46

14 years ago
(In reply to comment #43)
> How does MOZ_APP_DISPLAYNAME work with different forms of the name in different
> languages?  For example, assume the following two MOZ_APP_DISPLAYNAMEs:

MOZ_APP_DISPLAYNAME is set at build time and is not localizable, nor are
practially all strings it's used in (help text of the mozilla binary etc). All
localizable content is supposed to use chrome's branding stuff.

Comment 47

14 years ago
Comment on attachment 180057 [details] [diff] [review]
stage 1, additional fix 1: remove quoting trickery in bootstrap (checked in)

a=asa
Attachment #180057 - Flags: approval1.8b2? → approval1.8b2+

Comment 48

14 years ago
Comment on attachment 180058 [details] [diff] [review]
stage 1, additional fix 2: remove version.dtd (checked in)

a=asa
Attachment #180058 - Flags: approval1.8b2? → approval1.8b2+
(Assignee)

Updated

14 years ago
Attachment #180057 - Attachment description: stage 1, additional fix 1: remove quoting trickery in bootstrap → stage 1, additional fix 1: remove quoting trickery in bootstrap (checked in)
(Assignee)

Comment 49

14 years ago
Comment on attachment 180058 [details] [diff] [review]
stage 1, additional fix 2: remove version.dtd (checked in)

Both additional fixes for stage 1 checked in.
I hope we'll get clearance on the name soon so I can get to stage 2 a.k.a. "the
real thing" :)
Attachment #180058 - Attachment description: stage 1, additional fix 2: remove version.dtd → stage 1, additional fix 2: remove version.dtd (checked in)
(Assignee)

Updated

14 years ago
Depends on: 289846

Comment 50

13 years ago
Once you guys have your rebranding worked out, we'll work on getting you onto UMO.
Blocks: 288371

Comment 51

13 years ago
I don't see a bug about the splash screen? That needs to be rebranded, right?
(And perhaps change color to fit the new logo whatever that may be.)
(Assignee)

Comment 52

13 years ago
(In reply to comment #51)
> I don't see a bug about the splash screen? That needs to be rebranded, right?
> (And perhaps change color to fit the new logo whatever that may be.)

Artwork will be resolved after the alpha release, we'll take user submissions
for a logo, and the final splash screen will be created after we have such a
logo. We'll use some very primitve placeholder artwork for the alpha for the
time being, as we can't do a logo contest or something like that when we have no
publicly announced name yet.

Updated

13 years ago
Depends on: 293268

Updated

13 years ago
Depends on: 297823
(Assignee)

Comment 54

13 years ago
Created attachment 187687 [details] [diff] [review]
stage 2: do the real rebranding

OK, this is the real thing now.

Please DON'T shout out loud about it for now (_no_ blog entries, board threads
or similar stuff yet), we're preparing an official announcement for going
public with the name, and we want that to hit the news, not some random
bugzilla report and patch.

So, consider this patch unofficial as long as there's no announcement about a
new suite project with a new name out there.

Regarding the artwork: Most of the patch size is the splash.xpm image, and the
patch mentions quite some "binary" image files that will all have that
temporary placeholder artwork contributed by Chris Thomas. This WON'T be our
official artwork for 1.0, we'll open a channel for artwork/logo submissions
soon after going public.
Attachment #187687 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #187687 - Flags: review?(neil.parkwaycc.co.uk)

Updated

13 years ago
Attachment #187687 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #187687 - Flags: superreview+
Attachment #187687 - Flags: review?(neil.parkwaycc.co.uk)
Attachment #187687 - Flags: review+
(Assignee)

Comment 55

13 years ago
Comment on attachment 187687 [details] [diff] [review]
stage 2: do the real rebranding

requesting approval: suite-only change to rebrand trunk to use the new
"SeaMonkey" name throughout the product.
Attachment #187687 - Flags: approval1.8b3?

Comment 56

13 years ago
Comment on attachment 187687 [details] [diff] [review]
stage 2: do the real rebranding

a=bsmedberg
Attachment #187687 - Flags: approval1.8b3? → approval1.8b3+
(Assignee)

Comment 57

13 years ago
OK, we're ready to go code/patch-wise, but Chase is overloaded currently (no
time before the july 4 holiday) and can't do the infrastructure stuff atm.

We have to coordinate bugs 292268,285696,288199,289846,298901 to make it all
happen at once and make the transition as smooth as possible, so we'll push out
the whole thing a few days (this is all SeaMonkey-only so we don't have to care
about aviary 1.1a2 too much), I hope it'll be ASAP - still need to schedule an
impact date/time with Chase though.

Additionally, we'll have to wait a few days as well to get MoFo reviews on the
announcement which should go public in a tight timeframe around the happening of
those changes.
Please be warned it's coming up but patient at the same time.
(Assignee)

Comment 58

13 years ago
OK, stage 2 has landed and this bug should be fixed. :)

Note that Chase is working on resolving the tinderbox problems and
infrastructure changes with us right at this moment, and we're still waiting on
a review and OK for our announcement from Mozilla Foundation people (we're
talking about our realtion to them in there, so they need to sanction it).

Please wait just a bit longer until that's all done (trees green, builds
appearing at new places, announcement and new project page up at
http://www.mozilla.org/projects/seamonkey/ ) before shouting the message out
publicly.

It should hopefully be a matter of hours to days until we're set up completely.
Thanks for your patience and we hope to have a good future with that new,
rebranded product!
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 59

13 years ago
Any idea why this made Tp on btek go up from 835ms to 905ms?
I bet the new throbber is a lot slower to animate.  Could someone please test
that by backing out the new throbber and seeing what btek does?
throbber changes backed out
Well, that doesn't seem to have been it... what else could have changed?
throbber changes relanded...
(Assignee)

Comment 64

13 years ago
(In reply to comment #60)
> I bet the new throbber is a lot slower to animate.

Interestingly, the new placeholder throbber is even smaller in size than the old
one (which doesn't have to affect Tp directly).
What makes me wonder is that luna has no Tp changes at all.

Anyways, could we take discussion about the btek Tp problem and about Z changes
(which I'd like to have investigated as well) to a new bug?

Updated

13 years ago
Blocks: 299581

Updated

13 years ago
No longer blocks: 299581
I have to note... what I tried was classic throbber, but it looks like tbox may
actually be testing modern. someone should try backing out modern throbber.
I'm fine with a new bug if it's marked blocker.  An 8% Tp regression is pretty
unacceptable...
(In reply to comment #65)
> I have to note... what I tried was classic throbber, but it looks like tbox may
> actually be testing modern. someone should try backing out modern throbber.

I backed it out.
(Assignee)

Comment 68

13 years ago
Modern throbbers are back in, they also had no effect.

I filed bug 299624 for the btek Tp increase, and bug 299627 on the codesize
increase.
(Assignee)

Updated

13 years ago
Depends on: 299633

Updated

13 years ago
Depends on: 299581
(Assignee)

Updated

13 years ago
Blocks: 299883
This checkin affected the about:logo image for Camino. Please to be fixing ASAP.
yeah, what on earth is going on here?
(Assignee)

Updated

13 years ago
Blocks: 299897
(Assignee)

Comment 71

13 years ago
(In reply to comment #69)
> This checkin affected the about:logo image for Camino. Please to be fixing ASAP.

Filed as bug 299897
No longer blocks: 299897
(Assignee)

Updated

13 years ago
No longer blocks: 299883
Depends on: 299883

Updated

13 years ago
Depends on: 303259

Comment 72

13 years ago
What about bug #271745.  Something we need to do about it??
You need to log in before you can comment on or make changes to this bug.