Closed Bug 257117 Opened 20 years ago Closed 20 years ago

Standardize installer/tarball file names, and tinderbox build automation for localizations

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: benjamin, Assigned: benjamin)

References

Details

(Keywords: fixed-aviary1.0, Whiteboard: [has patch] need to coordinate staging automation)

Attachments

(4 files)

Standardize naming
21.92 KB, patch
bryner
: review+
Details | Diff | Splinter Review
Document describing filename convention
3.96 KB, text/html
Details
Prettify long names in post-mozilla-rel
1.54 KB, patch
Details | Diff | Splinter Review
merge remaining part of attachment 157272 to trunk
4.62 KB, patch
bryner
: review+
Details | Diff | Splinter Review 
Followup to bug 254175 and discussions on npm.l10n, we need to

1) standardize the names of release packages (tarballs and installers)

2) Set up build automation so that a tinderbox can show basic green/red for all
the locales in CVS, and produce nightly localized builds

The part of this that needs to go in the CVS tree (the makefile-fu) is pretty
simple. The part about setting up a tinderbox server shouldn't be hard, I
imagine... the only part that mystifies me is setting up the tinderbox client
(in post-mozilla.pl) to loop through a bunch of locales and send each one as a
separate tinderbox email pair.

Here's what the tinderbox client needs to do:

After the regular tinderbox build is complete (in English), and the packages are
staged, the tinderbox should loop through all the non-English locale dirs in
CVS, and do the following actions (ab-CD is the locale):

send an "I'm starting the tinderbox "ab-CD"
"make -C browser/locales installers-ab-CD"
send an "I finished ab-CD (red/green with a log)

and hopefully stage the resultant langpack+tarball+installer to FTP (or at least
the nightly build machines should do this).
Flags: blocking-aviary1.0PR+
Whiteboard: blocks l10n, but not PR
This standardizes the naming convention

product-version.b.c.locale.platform-info[.installer].extension
Comment on attachment 157272 [details] [diff] [review]
Standardize naming

This has been tested on win/linux, I'm trying to get a build up to test mac.
Attachment #157272 - Flags: review?(bryner)
Just to verify, this also works on mac, though I added an extra @rm -rf in
packager.mk for safety's sake. dbaron, you've been near this code recently,
maybe you could review this?
Whiteboard: blocks l10n, but not PR → [has patch] need review bryner or dbaron - blocks l10n, but not PR
So, how are the respective bits of the filenames built up here?

Are they following the proposal on n.p.m.l10n? or are they entirely different? I
really hate reading through the code to find that out, as I'm having trouble
enough finding the time for everything that's going on around me currently...
Blocks: 257463
Comment on attachment 157272 [details] [diff] [review]
Standardize naming

So what does this leave the installer filenames looking like?
firefox-0.9.0+.en-US.win32.installer.exe
firefox-0.9.0+.en-US.win32.zip
firefox-0.9.0+.mac.dmg.gz
firefox-0.9.0+.linux.tar.gz
firefox-0.9.0+.linux.installer.tar.gz
firefox-0.9.0+.linux-gtk1.tar.gz
firefox-0.9.0+.linux-svg-cairo.tar.gz
oops, all those mac/linux names were supposed to have en-US in them also
I object to the platform part for linux packages, as they don't state the
hardware platform, though this is needed for linux (at least). For linux, the
platform part has to contain at least the contents of the output of "uname -si",
i.e. linux-i686 for the current tier-1 platform. For win32 and mac, it look
acceptable, though I'd rather use "macosx" instead of just "mac".

I'd really like to see a pec for those filenames somewhere, somehow similar to
what I tried to make up in the n.p.m.l10n newsgroup in the posts that lead to
thais change here.
If we have such a spec available, it's much easier to name files in other places
as that script accodingly.
Damn, I posted my explanation too quickly. Robert, the convention is I belive
what you and I discussed on IRC, and of course it includes a linux-<processor>.
I need at some point to add RegExp to the attached doc.
That convention really looks nice to me, we'll use the same convention for all
MLP packages. I guess that's the first time we ever have one convention :)

One thing is left on my mind though: I'd be quite happy to apply it to Seamonkey
as well ;-)
Waht about that? Any chance? (We'll use it for MLP Seamonkey packages beginning
with 1.8a4, but I'd really appreciate the official builds following the same
convention.)
> One thing is left on my mind though: I'd be quite happy to apply it to Seamonkey
> as well ;-)

You write the patch, I'll review it. You can even get
xpinstall/packager/Makefile.in to include toolkit/mozapps/installer/packager.mk
since seamonkey depends on toolkit now. Unifying the logic in toolkit is a good
thing. I'm just too busy and have too many trees to start hacking in more places.
As posted in the newsgroup:
* How do I tell the difference between an Official Release and a "Community
Edition" Release ?

I know CE builds are not being made by Mozilla.org, but they will hopefully be
hosted on the mozilla.org ftp servers and therefor the naming convention should
take those into account

The quick answer would be different ftp directories but I don't find that
sufficient since it wont be visible after download.

my suggestion:

-Suffix the "Application Name" part with uppercase CE for Community Edition like
firefoxCE,thunderbirdCE.

possibly with a dash betweeen like firefox-CE,thunderbird-CE


* another question, how is linux 64bit shown ? (I'm currently not at home so i
can't do a uname )
Some comments:
 * Do we need the version number in the filenames?  We haven't done that in the
past for nightlies, only releases, and it's going to be in the directory name. 
So maybe it's easier to skip that part?

 * mscott thinks the windows names should start with an uppercase letter

 * jst wonders whether we want the "installer" to be the shorter name --
although that may cause confusion since people might expect exes or zips/tar.gzs
to be simple self-extracting archives or simple archives.
(In reply to comment #13)
> Some comments:
>  * Do we need the version number in the filenames?  We haven't done that in the
> past for nightlies, only releases, and it's going to be in the directory name. 
> So maybe it's easier to skip that part?

Better not. People downloading files would like to know what they have lying
around on their harddisk. Additionally, see the URL I'm gioving you below.

>  * mscott thinks the windows names should start with an uppercase letter

We have debated uppercase vs. lowercase letters in n.p.m.l10n and the big
concern is that it destroys ordering of the files on case-sensitive platforms
(see the newsgroup).
Additionally, I don't think Windows users are concerned if it's an upper or
lower cased character that their files are starting with.
 
>  * jst wonders whether we want the "installer" to be the shorter name --
> although that may cause confusion since people might expect exes or zips/tar.gzs
> to be simple self-extracting archives or simple archives.

Most people won't type the filenames by hand, so I think the length of the names
are not the primary concern - and I think that file names should undoubtedly say
what's in the file.

Please see the discussions in n.p.m.l10n that lead to that proposal here, and
please also look at the GNU HOWTO on package filenames at
http://en.tldp.org/HOWTO/Software-Release-Practice-HOWTO/naming.html
We don't ship "official" zip builds on Windows, so I'll reiterate my
'requirements' for the Windows file name for the installer:

Firefox Setup (1.0, en-US).exe

(if you want to omit the version number, feel free to do so, although it allows
you to have more than one installer in the same directory)... 

Spaces are legal on Windows, and allow the file name to wrap when displayed in
the shelll, i.e. when it is downloaded to the desktop. Currently when a user
downloads Firefox on Windows they probably see:

   ////
   ////
   ////
FirefoxSetu...

With the scheme I propose, they will see:

   ////
   ////
   ////
Firefox Setup
(1.0, en-U...

Which is a lot more useful. All of the characters in my proposed format are
legal in Windows file names. 
and on Mac the file name should be:

Firefox (1.0, en-US).dmg.gz

I obviously do not agree with what Ben says here, but then I'm only a
representing the MLP here (localizers seems to very largely agree with me), and
as long as the MLP hasn't have to follow Ben's conventions and we can follow our
own for our builds, we'd rather go with what the here attached document says.
For the arguments to that please see n.p.m.l10n, I don't want to copy & paste a
discussion here, as newsgroups are much better fit for discussion as bugzilla.
>Additionally, I don't think Windows users are concerned if it's an upper or
>lower cased character that their files are starting with.

Yes we are concerned with the case sensitivity on Windows. Windows installer
names should start with a capital letter. Unix users are used to lower case
letters and that's fine. The standard doesn't have to be the same across
platforms. Leave it lower case for the linux and upper case for windows. 

I know the convetion on Linux is to have really long names with all the variants
of what's in the package reflected in the name. That's fine to leave the linux
standard for our packaging scheme, but it's inappropriate for Windows where this
is not the convention. 

The GNU document you cite was written from the perspective of a linux user. Even
all the examples are linux and os x package names. Those patterns are not
expected on commercial windows applications. I can't wait to see
microsoft-office-9.5.0+.win32.installer.exe! oh my! :)
I was talking about what's best for users (my comments were based on where
strings wrap in the Windows Shell, how to maximize readability etc), not what's
best for developers or localizers. Shouldn't users be who we think about first? ;-) 
All the Microsoft installers I download are called things like dxsetup.exe or
vcsetup.exe.  Other ones (for drivers, etc.) are usually even more cryptic, or
just called "setup.exe" -- gee, thanks.

They don't use spaces anywhere that I've seen, and I wonder if it's for a reason.
(In reply to comment #18)
> The GNU document you cite was written from the perspective of a linux user. Even
> all the examples are linux and os x package names. Those patterns are not
> expected on commercial windows applications. I can't wait to see
> microsoft-office-9.5.0+.win32.installer.exe! oh my! :)

Let me check what I got in my download folder here:

j2re-1_4_2_04-windows-i586-p.exe
WindowsXP-KB835935-SP2-DEU.exe

so even Microsoft uses longer names. They never use space though. Im am sure it
has a reason.
As you can see in the JRE-example: all-lowercase-filenames are used on Windows,
too. I vote for the firefox filenames being all lowercase. For the average
Windows user it does not make a difference, they just don't care. But uppercase
messes things up on servers and other Linux/Mac machines.

In general, I fully agree to the convention proposed by attachment 157639 [details]. The
average user does not care whether the file is named "Firefox-Setup.exe" or
"firefox-1.0.de-DE.win32-svg-gdiplus.installer.exe". They just see "Firefox" and
thats fine. But the more advanced user wants to know all the information that is
included in the long filename. 
The same for nightly builds, it would be nice to have the date in the filename.
Right now, one has to rename every nightly :(


Another topic we discussed on IRC last night:
Community builds. I propose adding a "-community" to e.g. "firefox-1.0", which
makes "firefox-1.0-community.en-US.win32.zip". putting it there does not mess up
alphasorting and it is still understandable.
It's completely reasonable, and can be much better for usability, to observe
platform conventions.

If Windows or MS is inconsistent, that doesn't mean we should impose a Unix-y
filename convention on Windows *users*, especially not for our own convenience.
Our scripts and servers can cope.

I think Ben makes a good usability argument.  Mac is inherently different, and
our Windows names could usefully follow suit.

/be
while I do think ben's suggested filename is better, I do not think this is
platform convention. can you name say 3 installers that use spaces in their
filename?
biesi: separate paragraphs in comment 22 advanced separate thoughts; I don't
know why you are mixing them.  I did not say "use Ben's proposed convention
because it's the platform standard".  In fact I thought I called out how
Mac-like the proposal was, but that we should use it on Windows too, anyway. 
And I said "Ben makes a good argument [independent of platform standards or lack
thereof]."

It's not as if there is a strong convention on Windows that actually benefits
users, as shaver pointed out in comment 20, first paragraph, last sentence in
particular.  Users are not going to hate us for not calling it setup.exe, but
many may actually thank us, or would if they knew what was at stake, for using
more usable filenames.

So if I really believe what I wrote, I'm saying follow platform conventions, or
be willing to -- don't force GNU or Unix-y standards on other OSes.  *And* I am
saying "make Windows more Mac-like".  Two separate thoughts, not original to me
and not in conflict, due to the weakness of the Windows "setup.exe" convention.

/be
A slightly modified version of my proposal may work better (for English at
least) as:

"Firefox Setup (1.0,en-US).exe" instead of "Firefox Setup (1.0, en-US).exe"

because my experimentation shows that the shell displays the former as:

   ////
   ////
   ////
Firefox Setup
(1.0,en-US...

which displays the whole locale name. Of course this may be moot in other
languages if the word "Setup" localized is a longer word that wraps around onto
the next line. 

Requirements:
- Keep the set of information presented to a minimum
- Respect the nature of file names on platforms like Windows and Mac to contain
human readable content in the form of real sentences and capitalized names. 
- Characters closer to the start of the string are more important than
characters towards the end of the string, depending on shell cropping/wrapping.
It is most important to use characters towards the start to display information
about what the file is - people should know that it is the Firefox Setup program
first - not Firefox-someth... which they might think is the application itself
or something else entirely. 

The reason I'm harping on about this so much is that organizations like Netscape
did studies that showed that you might convince someone to click on a download
link on a web page for your software but a large number of people believe they
have then installed the software, or forget where the file went or what it was
called, and have no idea how to find it. For that reason they never install the
software. This is such a huge problem that we are aggressively optimizing every
stage of the install process to make it more likely that people will figure out
how to download and install our software. 

Even if something makes "sense" per some GNU document guideline or from an
engineering point of view or from a parsing/tools point of view - was it worth
it to follow that path if even one person would have been able to install the
software but couldn't because they lost the file? Please don't tell me it was.
We're building software for everyone after all, not just ourselves. 

I'm not aware of any technical impediments to such a scheme on Windows/Mac - I
renamed the setup program I downloaded off the website to the name I talk about
above and ran it - my computer did not catch fire - all seemed to run properly.
I'm not interested in hearing FUD style arguments to the effect of "there must
be some reason but I can't name it."
OS: Linux → All
Hardware: PC → All
(In reply to comment #25)
> I'm not interested in hearing FUD style arguments to the effect of "there must
> be some reason but I can't name it." 

This effectively means for me that the MLP and official builds will use
different naming conventions after all, as we have to care about making the work
doable by all our contributors. Having the builds available in all languages and
linked from mozilla.org pages is actually more important to us than some users
being too dumb to being able to find the files they downloaded. Sorry. (Anyways,
my personal opinion is that those users should better not download any files at
all, letting aside if they should even touch a computer.)

It would have sounded nice to have one common convention, but at least now we
know why we obviously can't.
Benjamin, thanks for the document attached here, as it's very likely to get the
standard for the MLP contributed builds at least.
I'm not as concerned about what unofficial or "community edition" files are
called. I want to ensure that all "Mozilla Official" software is well-named
first. So do what you will. 

What I am concerned about is labelling users things like "dumb." They're not
dumb at all - they have better things to do with their lives than know all the
details about how their computers work. Our job as software engineers is to
design software so good that it seems intuitive to them so that they have to
know less to get their work done. That is and has always been the goal of Firefox. 

As far as whether or not file names with spaces are feasible, I've been doing
some testing on ftp.mozilla.org, creating files named as I have described above,
and downloaded them in several ways - from Firefox by clicking on the file link,
from IE by clicking on the file link, from IE by opening a direct link to the
file where the spaces were encoded as %20 in the link, in every case the file
downloaded and the spaces were correctly present in the file name. In every case
the installer ran. Some detail: The file on the server is actually a 7zip
installer wrapper, which wraps the real installer "setup.exe" - the 7zip
installer deflates the setup.exe and associated files to a temporary location
and runs them, so as far as the code is concerned, nothing has changed. 
Robert Kaiser wrote:

> Having the builds available in all languages and linked from mozilla.org pages
> is actually more important to us than some users being too dumb to being able
> to find the files they downloaded. Sorry.

That "Sorry" rings false, and the sentence before it makes no sense.  Having all
builds available in all languages and linked from mozilla.org pages in no way
conflicts with having user-friendly names for the top two desktop platforms.

If localizers don't care about usability, then what's the point?  To amuse a
small group of GNU-aware hackers and fans?

> (Anyways, my personal opinion is that those users should better not download 
> any files at all, letting aside if they should even touch a computer.)

You're a dreadful snob, then, and you are bound to be frustrated by such base
users when working on Mozilla localization.

Most people who use computers are not and will never be Unix hackers, nor will
they grok GNU filename conventions.  If you really mean to say most such people
should not use computers, then you are on the wrong project.  Mozilla products
are used by millions of people, most of whom do not handle long-winded Unix-ish
filenames well at all.

/be
It's not my style discussing side issue here, but I'm making an eception here:

(In reply to comment #28)
>> Having the builds available in all languages and linked from mozilla.org pages
>> is actually more important to us than some users being too dumb to being able
>> to find the files they downloaded. Sorry.
> 
> That "Sorry" rings false, and the sentence before it makes no sense.  Having all
> builds available in all languages and linked from mozilla.org pages in no way
> conflicts with having user-friendly names for the top two desktop platforms.

The problem is that following probably 3 different standards for the files we
are uploading and ensuring they are dealt with correctly is too much work for
the people of our MLP team. And remember that Linux is a desktop platform as
well (I doubt people will run Mozilla without a "Desktop" or a window manager),
so we have actually three desktop languages.

And I still think that a user that realizes what (s)he's doing can cope with a
longer filename, and I even believe that Windows and especially Mac users can
treat those filename well.

And if they double-click that long filename on their Desktop (I know that
Windows is insane enough to download files to the Desktop sometimes), they will
start the installer as well - or open the .zip file if it is the zip package.

> Most people who use computers are not and will never be Unix hackers, nor will
> they grok GNU filename conventions.

I never said computer users should be Unix hackers, I only said if they are not
able to read a filename, even if it's long and seperated only by hyphens and
dots, then it might be better they do nopt use a computer.
Remember that most users will name their documents with quite long names as well
(just try to use the default name on a Word document, it's the beginning of the
document in most cases - though I admit that introduces lots of spaces in the
name usually).
> The problem is that following probably 3 different standards for the files we
> are uploading and ensuring they are dealt with correctly is too much work for
> the people of our MLP team.

Ok, too much work == not doable, your first sentence in comment 26.  That was
not clear, as the second sentence went on to talk about having the build
available in all languages and linked from mozilla.org pages, which is quite
possible with platform-specific names, given the will to use such names.  Thanks
for making this clear.

> And remember that Linux is a desktop platform as well (I doubt people will run
> Mozilla without a "Desktop" or a window manager), so we have actually three
> desktop languages.

Of course -- I use FC1, how could I be forgetting Linux in what I wrote?  I was
clearly talking about the top two majority market share platforms.  Linux on the
desktop is a long way from being a threat to Windows or Mac, in part because of
usability problems in its desktop, in part due to crufty filenames.

What you think, or assert without evidence, about how users can cope with long
hyphenated filenames, is not relevant to whether the l10n teams can cope with
platform-specific filenames, so I'm not sure why you bother asserting that any
user can cope with such names.  The experience Netscape has had contradicts your
assertion.  My family members who are not computer-savvy misplace files all the
time, especially ones with names that do not look like proper noun phrases.

Again, if you say that users who cannot cope with long, hyphenated, crufty names
should not use a computer, you are saying that the vast majority of users, and
of potential users, should not use a computer.  And that's antithetical to the
project, so it will cause you stress in the future.  This is not the last time
we'll face such an issue.

/be
Well, it seems to me that things go amiss here...
obviously we will not be able to find one convention for all platforms. Thats
sad, but it might be the truth.
So we should think how we can get the best out of the situation.

Lets start with the simplest platform: Linux. I hope we all can agree on one
convention here.

Windows is next: there is no real common convention for Windows filenames, and
not being active on Windows much I will skip this one.

MacOS X: Here we actually seem to have a common convention, all files I
downloaded from Apple and other sources have the following format:
AirPortDrivers.dmg
CoreAudioSDKApril2003.dmg.bin
MacOSXUpdateCombo10.3.3.dmg
ChickenOfTheVNC1.3.6.dmg
This format might make machine-parsing a little tricky, but it might be
possible. I am no programmer (yet), so somebody else please comment on that.
One thing is for shure, though: They never use spaces and they are consistent in
it! If we want the filenames to line-wrap we could use hyphens, those do
line-wrap. Lots of OS-X users also use the Terminal.app sometimes, and with the
default shell being tcsh, spaces do *not* autocomplete.

I also want to help finding a convention that is user-friendly, even to
unexperienced users. But then we should not violate platform conventions where
they exist. And introducing spaces in Mac filenames is such a violation.
On the other hand, I also want to help finding a convention that does not put
too much load on us of the MLP staff, and furthermore is still informative for
experienced users.

I hope this can somehow be achived.
> Lets start with the simplest platform: Linux. I hope we all can agree on one
> convention here.

I think the attached convention does work well there.

> Windows is next: there is no real common convention for Windows filenames, and
> not being active on Windows much I will skip this one.

I tend do understand Windows programmers and users less and less, so just do
what you want there. <joke>Perhaps call it Setup.exe, that doesn't scare people
that much away as anything mentioning product names or version numers might
do.</joke> ;-)

> MacOS X:

Uh, those filenames you mention are neither machine-parseable nor human (user)
readable in a good way, they really scare me - even more than ben's proposals :)

> If we want the filenames to line-wrap we could use hyphens, those do
> line-wrap.

Now that's interesting. That means, my original proposal that has only
hyphen-seperated names (use attached convention and replace all dots that are
not in version number or seperating tht extension[s] with hyphens) would have a
godd user experience there, as do current MLP and official seamonkey file names?
Cool, though being less machine-parseable, that style might work for both mac
and unix then.

> But then we should not violate platform conventions where they exist.

Interestingly, there's a GNU convention (consider this a convention for Linux)
and there seems to be something like a convention or rules for MacOS X, but no
more-or-less official thing for Windows (other than just "Setup.exe").
There's only ben's fear that the filenames might look bad on Windows Desktop.
(<joke>Hasn't the Redmond Empire remembered that hyphens are expected to wrap in
printed language - or is this an unfinished feature?</joke>)

I see this fear because I happen to know some of those users as well (and
brendan, yes, we might have the conflict you've spoken of again as I'm coming to
that conclusion quite often, but I'd rather not elaborate on that right now).
I've never seen those people having problem with double-clicking the file they
downloaded though (in my experience, they're double-clicking too many files
without thinking, rather than too little).

All that reminds me of the proposal Gerv made in the newsgroup: We can name the
files on FTP according to the convention and symlinking them to short, simple
Joe-Windows-User-like names like FirefoxSetup.exe or whatever.
I'm only a minor user of Firefox.  I'm a programmer, and have been for more than
8 years, but I also offer technical support - I've done so in schools even.

For example, a teacher at the high school I went to - who taught web design no
less - could be seen to do things that, well, are looked upon badly by technical
people.  For one, she could be seen numerous times just clicking "OK" on a
dialog, and shortly after asking why thing weren't working. (even though the
dialog was warning her of problems...)  Other times, she would lose files or
have other problems that seemed to me to be so easy.

But she was certainly not stupid, and she was still a teacher.  The students
learned things from her.

I would just like to echo Ben Goodger's comments, essentially.  Some people may
appear to be "stupid" or "dumb", but this usually isn't at all the case.  As
I've said to others, you may think it simple to tame your computer, but would
you find it simple to tame a lion?  Because there are people who would find that
easy, and would find taming even Microsoft Word a task indeed.

Hyphens may wrap in Mac OS X, but they do not on Windows XP.  While there's no
real convention on Windows, there is a significant point to using spaces.

I used to help coach the Academic Decathlon team at said high school. (and I was
in it when I went...)  I worked with people who were, no joke, the smartest in
the entire school.  At times, I helped them with computer questions - and they
had trouble too.

Should people with IQs possibly higher than even our own be "banned" from using
computers simply because they don't have as good a hold as us elitists?  I'm
sorry, but that mantra really bugs the **** out of me.  Especially when I think
of those people in the above team.

I have personally had to help people find files they downloaded.  Even my own
mother, who has been using computers, DOS, Windows 3.11, and the like since I
was born.

If you're looking for a convention on Windows file names, start with your C:\. 
Documents and Settings.  Local Settings.  Temporary Internet Files.  That is the
convention.  It may be Microsoft's convention, but it does make sense.  Even I
prefer files on my desktop to have spaces, for the simple reason that they are
easier to find that way.

Further, I don't see ~Firefox Setup \(([^,]+?), ([^)]+?)\)\.exe~ to be hard to
parse at all.  Yes, not following a single convention can make it a bit of a
pain... but if all programmers did was make things easy on themselves, we'd have
things like... well, many of the current programs :P.  But I thought that
Firefox was different.  I thought that was what Firefox was about.

For me, programming has been and always will be about those people affected by
your program.  Not just those using it - those affected by it.

But who am I?  Some little punk interfering in the discussion of all of you, I'm
sure.  I'm sorry if I've wasted anyone's time - but I still harbor the hope that
maybe someone will actually consider that not everyone likes GNU filenames.
(even though I like them for most cases, and would prefer the zips used them not
the Firefox Setup (1.0, US).exe convention....)

Thanks,
Unknown W. Brackets
(In reply to comment #32)
> > MacOS X:
> 
> Uh, those filenames you mention are neither machine-parseable nor human (user)
> readable in a good way, they really scare me - even more than ben's proposals :)

Well, they seem to be Mac-user readable. And the last time I met a Mac user, he
looked human to me. ;)
I did say that they would not be easy to parse, but I doubt it is impossible. 

So for Mac there are IMHO only two acceptable formats: 
1. The format the whole Mac world uses: titlecase, no separation
2. some hyphenated form
(or a combination of these two)
*NOT* acceptable on Mac would be however a filename with spaces. But I keep
repeating myself... 
I have no objections to the intention of Ben's proposal but I have a few issues
with it

I however have serious issues with his current proposal:

* Filenames Should not contain spaces. They are PITA to work with, which is why
you never see it on the internet.
If you go to download.com or other such places, how many files with spaces do
you see ? I have found none.

in remarks to comment #33 , those files you mention has spaces in them that is
correct, but none of them it something you downloaded. They are all something
you or an installer has created.The same properly go for all the stuff with
spaces in on your deskop, not downloaded, installed.

* We should not use Parantheses "(" & ")" or comma. Again they may be legal,but
not very userfriendly

For the first it makes spelling the thing harder,people are not used to such
letters in filenames, and thus they must use greater effort to understand/use/ etc.

Secondly they are very hard to read out load when you are talking e.g. office or
student talk.
the link Firefox Setup (1.0RC,fr-FR).exe" aloud to a friend
"Firefox(Space)Setup(space)(Paranthese start)1.0(comma)fr-FR(parenthese end).exe.

It just doesn't sound well, and your friend will most likely misspell it.

Lets take an example where a student has downloaded it to a network share and is
telling people about it.

"It is on the work share, under my name, and it is called FireFoxSetup one dot-o
english.exe"

versus

"It is on the work share, under my name, and it is called FireFox Setup
(paranthese start)one dot-o (comma) engish (paranthese end).exe"

This is normal talk (at least in my part of the world).



The question is now what is the next step, Is someone going to sit down and
create a new proposal based on (approx) the following requirements. (or if MF is
going to trumph it and require spaces and Paranthese)

Requirements (my ideas):
* One unified standard for all mozilla.org products suite,fox and the birds
* A standard that blends well with the platforms
* A standard that does uses short names where possible
* A standard that does not use spaces and other characters that may be legal,
but it little used elsewhere and which in turn will confuse users.

I agree with comment #35
Why complicate matters when the examples in comment #6 and attachment from
comment #9 describe a good, simple format that, with a few minor tweaks, can do
everything we want.
I think it's already been said why people want to complicate matters - because
the names will be more readable on the Windows desktop. That does seem to make
this bug a bit wontfix-ish though - if we're going to have localised filenames
in a different format on each platform, that's not really standardising anything...
Of course there can be standards for file names that are platform-specific. 
They are still useful, to keep people from inventing yet more conventions or
names instead of following the (platform-specific) standard.

I have no idea who "MF" is in comment 35, but it's not any person, AFAIK.  Argue
against ideas, not people or imaginary monsters, please.

/be
bsmedberg says this work does not actually block PR, just l10n
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0PR+
Flags: blocking-aviary1.0+
One thing that would be nice about cross-platform naming schemes is that those
few that actually make it to a ftp directory listing don't start to think whether
they get the same app for a different OS or different apps alltogether.
"Where is "Firefox Setup (1.0,en-US).exe" for the Mac?"
It'd be even worse if we get bugs that it doesn't work :-/.

Am I completely mistaken in that the whole argument for the above name is merely
for windows users downloading that file onto the desktop?

No wonder the arguments grow out of hand, one popular use case with one particular
issue fixed, all other use cases not.
Just adding two small comments, which  should be taken into consideration
regardless of the use of spaces

* Even on windows we have (or will have) different platforms. There is both
"normal"  windows and 64bit windows (currently in beta). I know Mozilla.org does
not yet produce win64 builds, but we should still consider it.

* The is also the community edition builds (as defined in the l10n trademark
guidelines), how will they be named ?
Just to point out an ongoing discussion on n.p.m.l10n (which could be more
appropriate to discuss the current issues in the proposed naming scheme)

http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&c2coff=1&threadm=mailman.1094600581.25586.mozilla-l10n%40mozilla.org&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26c2coff%3D1%26group%3Dnetscape.public.mozilla.l10n
> No wonder the arguments grow out of hand, one popular use case with one
> particular issue fixed, all other use cases not.

The use case you say is fixed is the one that matters, because the user is the
mass-market Windows user, on average.

Other use cases you refer to must mean localization folks having to rename files
when delivering them to the ftp server, or something like that.  Comment 19
makes this distinction.  Is it lost on people still, or are localization folks
unwilling to consider putting mass-market usability ahead of their own?

The bash comment in the google groups post seemingly linked to in comment 42 is
pretty irrelevant, as very few Windows users would reach for bash to deal with a
downloaded Firefox package.

/be
> The use case you say is fixed is the one that matters, because the user is the
> mass-market Windows user, on average.
...
> The bash comment in the google groups post seemingly linked to in comment 42
> is pretty irrelevant, as very few Windows users ...

Sure. But (assuming that you/Ben aren't proposing that Firefox drops support for
everything except Windows), we do need to deal with non-average users who aren't
on Windows too. There was a proposal which covered everything, and that proposal
was rejected and replaced with a vague specification for Windows only.
Presumably someone needs to come up with a new proposal...

Usability for users is obviously important. On the other hand it doesn't help
end users if they end up with delayed builds, broken links and missing/incorrect
files because the delivery process has broken down. The process seems to have
problems as it is, so it would be good to simplify it rather than making it more
complicated, which was the aim of this bug, AIUI.
Another contructive suggestion (which has allready been mentioned, but deserves
a repeat)

Why not symlink the user friendly names (with spaces and all) to the standard
based ones. This can be done for release only, since nightlies is not for mass
market. or it can be automated.

As I see it, we get the best of both world:
* Ben gets whatever filename he chooses.
* the l10n people can use the standards they argreed upon.
* "The servers and scripts can cope" - brendan comment #22. They know the
standard l10n people go by, so they can easily script creation of symlinks.





Comment 44 seems to ignore the very explicit words I wrote in comment 38 first
paragraph, about standards being useful even if platform-specific.  Whoever said
that the Windows name scheme proposed by Ben should be used elsewhere?  Everyone
advocating different strokes for different platforms has either stated or
assumed that the long-lower-case-hyphenated-names are good for Linux and other
Unixy OSes.

I like Henrik's proposal in comment 45.  Thanks, Henrik!

/be
I wrote:

> I like Henrik's proposal in comment 45.  Thanks, Henrik!

As Henrik points out, Robert Kaiser (for one; perhaps others did too) already
made the symlink suggestion, albeit with RunTogether.exe Windows names, in
comment 32. Sorry I didn't reply to that earlier.

Anyway, this hybrid approach seems like it satisfies both classes of users
(use-cases, ugh).  Doesn't it cry out for some kind of table-driven automation,
so we can keep track of regular filenames and symlink names?  What would be
patched to implement this?  Who would do the patch?  Benjamin, is that you?

/be
> Anyway, this hybrid approach seems like it satisfies both classes of users
> (use-cases, ugh).  Doesn't it cry out for some kind of table-driven automation,
> so we can keep track of regular filenames and symlink names?  What would be
> patched to implement this?  Who would do the patch?  Benjamin, is that you?

It depends on where the automation happens. It can't really happen at the
mozilla build, it would have to either happen when builds are staged by the
post-mozilla tinderbox script or it would have to happen by some automated
process on ftp-stage. But it would sure make my life easier, as this patch could
just land as-is ;)  Doing it in post-mozilla might not be that hard, and I could
at least take a crack at it. Doing it as an automated process on stage is beyond
me, and myk is overburdened.
Blocks: 259605
Comment on attachment 157272 [details] [diff] [review]
Standardize naming

>--- /dev/null	1 Jan 1970 00:00:00 -0000
>+++ toolkit/mozapps/installer/package-name.mk	28 Aug 2004 20:53:10 -0000
>@@ -0,0 +1,84 @@
>+# ***** BEGIN LICENSE BLOCK *****
>+# Version: MPL 1.1/GPL 2.0/LGPL 2.1
>+#
>+# The contents of this file are subject to the Mozilla Public License Version
>+# 1.1 (the "License"); you may not use this file except in compliance with
>+# the License. You may obtain a copy of the License at
>+# http://www.mozilla.org/MPL/
>+#
>+# Software distributed under the License is distributed on an "AS IS" basis,
>+# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
>+# for the specific language governing rights and limitations under the
>+# License.
>+#
>+# The Original Code is Mozilla Communicator client code, released
>+# March 31, 1998.
>+#
>+# The Initial Developer of the Original Code is
>+# Netscape Communications Corporation.
>+# Portions created by the Initial Developer are Copyright (C) 1998
>+# the Initial Developer. All Rights Reserved.

This should have a new copyright unless you copied the code.

>--- /dev/null	1 Jan 1970 00:00:00 -0000
>+++ toolkit/mozapps/installer/packager.mk	28 Aug 2004 20:53:10 -0000
>@@ -0,0 +1,235 @@
>+# ***** BEGIN LICENSE BLOCK *****
>+# Version: MPL 1.1/GPL 2.0/LGPL 2.1
>+#
>+# The contents of this file are subject to the Mozilla Public License Version
>+# 1.1 (the "License"); you may not use this file except in compliance with
>+# the License. You may obtain a copy of the License at
>+# http://www.mozilla.org/MPL/
>+#
>+# Software distributed under the License is distributed on an "AS IS" basis,
>+# WITHOUT WARRANTY OF ANY KIND, either express or implied. See the License
>+# for the specific language governing rights and limitations under the
>+# License.
>+#
>+# The Original Code is Mozilla Communicator client code, released
>+# March 31, 1998.
>+#
>+# The Initial Developer of the Original Code is
>+# Netscape Communications Corporation.
>+# Portions created by the Initial Developer are Copyright (C) 1998

Same.  This code seems to have come mostly from xpinstall/packager/Makefile.in,
so this might be ok.

Looks ok otherwise, but please don't land this until we have post-mozilla
changes to fix the windows/mac intstallers to the "friendly names".
Attachment #157272 - Flags: review?(bryner) → review+
How about shoving each platform's builds into separate directories, then
scrapping the platform in the filename?

firefox/releases/1.0/en-US/win32/Firefox-1.0 Setup.exe
firefox/releases/1.0/en-US/win32/Firefox-1.0.zip
firefox/releases/1.0/en-US/macosx/Firefox-1.0.dmg.gz
firefox/releases/1.0/en-US/linux-i686-gtk2+xft/firefox-1.0.installer.tar.gz
firefox/releases/1.0/en-US/linux-i686-gtk2+xft/firefox-1.0.tar.gz

Yeah, it's kind of a drag, but it makes the filenames on *all* platforms more
readable.
good, so then people won't know if they have a binary for os/2 or windows, or
one for ppc or intel.
Whiteboard: [has patch] need review bryner or dbaron - blocks l10n, but not PR → [has patch] ready to land, need to coordinate staging automation
(In reply to comment #51)
> good, so then people won't know if they have a binary for os/2 or windows, or
> one for ppc or intel.

If there are other cues to the platform you are downloading (descriptive link
from a webpage, appropriate ftp directory name) I really don't think it's
necessary to have the platform in the filename to know whether the binary I
download is appropriate for my platform.
Whiteboard: [has patch] ready to land, need to coordinate staging automation → [has patch] need to coordinate staging automation
There has been at least one report at MZ forums about problems with downloading
1.0PR due to the spaces in the filename (though only in an unusual situation):

http://forums.mozillazine.org/viewtopic.php?t=131241

(In reply to comment #53)
> There has been at least one report at MZ forums about problems with downloading
> 1.0PR due to the spaces in the filename (though only in an unusual situation):
> 
> http://forums.mozillazine.org/viewtopic.php?t=131241
> 

If the link has "%20" or "+" in it, it shouldn't cause problems at all - even
Google uses that, I mean come on :P.

So, the real issue is that these:

var gWin32DownloadLink =
"http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/0.10.1/Firefox Setup
1.0PR.exe";
...
var gMacOSDownloadLink =
"http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/0.10.1/Firefox
1.0PR.dmg.gz";
 
Should be:
var gWin32DownloadLink =
"http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/0.10.1/Firefox+Setup+1.0PR.exe";
...
var gMacOSDownloadLink =
"http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/0.10.1/Firefox+1.0PR.dmg.gz";

At http://www.mozilla.org/products/firefox - that would solve any issues with
Netscape 4.x, etc...

-[Unknown]
(In reply to comment #54)
> Should be:
> var gWin32DownloadLink =
>
"http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/0.10.1/Firefox+Setup+1.0PR.exe";
> ...
> var gMacOSDownloadLink =
>
"http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/0.10.1/Firefox+1.0PR.dmg.gz";
> 
> At http://www.mozilla.org/products/firefox - that would solve any issues with
> Netscape 4.x, etc...
> 
> -[Unknown]

My mistake, s/+/%20/.  Although, generally + is accepted as a space...

Sorry for the bugspam...

-[Unknown]
(In reply to comment #55)
> My mistake, s/+/%20/.  Although, generally + is accepted as a space...

No, + wouldn't work at all.  That's a convention for CGI parameters, not a rule
for URLs.
This patch updates the tbox automation to create prettyname symlinks, got
r=timeless over IRC
Patch checked in on branch. This will get merged to trunk with all the other
localized-installer changes, once l10n-in-tree locations are settled.
Status: NEW → RESOLVED
Closed: 20 years ago
Keywords: fixed-aviary1.0
Resolution: --- → FIXED
This may have caused a regression for SVG builds...I just tried to do a build
following this checkin and got the following result:

set -e;  \
for i in packages-static config.it uninstall.it installer.cfg ; do \
  /usr/bin/perl /cygdrive/c/MozillaRoot/mozilla/config/preprocessor.pl -DAB_CD=e
n-US -DPKG_BASENAME=firefox-0.10.en-US.win32 -svg -D_IMPL_NS_GFX -D_IMPL_NS_MSG_
BASE -D_IMPL_NS_WIDGET  -DOSTYPE=\"WINNT5.1\" -DOSARCH=\"WINNT\" -DX_DISPLAY_MIS
SING=1 -DMOZILLA_VERSION=\"1.7.3\" -DHAVE_SNPRINTF=1 -D_WINDOWS=1 -D_WIN32=1 -DW
IN32=1 -DXP_WIN=1 -DXP_WIN32=1 -DHW_THREADS=1 -DWINVER=0x400 -DSTDC_HEADERS=1 -D
WIN32_LEAN_AND_MEAN=1 -DNO_X11=1 -D_X86_=1 -DD_INO=d_ino -DMOZ_DEFAULT_TOOLKIT=\
"windows\" -DMOZ_DISTRIBUTION_ID=\"org.mozilla\" -DMOZ_PHOENIX=1 -DMOZ_XUL_APP=1
 -DMOZ_APP_NAME=\"firefox\" -DOJI=1 -DIBMBIDI=1 -DMOZ_VIEW_SOURCE=1 -DMOZ_XPINST
ALL=1 -DMOZ_JSLOADER=1 -DMOZ_MATHML=1 -DMOZ_SVG=1 -DMOZ_SVG_RENDERER_GDIPLUS=1 -
DMOZ_LOGGING=1 -DMOZ_USER_DIR=\"Mozilla\" -DMOZ_XUL=1 -DMOZ_PROFILELOCKING=1 -DM
OZ_DLL_SUFFIX=\".dll\" -DJS_THREADSAFE=1 -DNS_PRINT_PREVIEW=1 -DNS_PRINTING=1 -D
MOZILLA_LOCALE_VERSION=\"1.7\" -DMOZILLA_REGION_VERSION=\"1.7\" -DMOZILLA_SKIN_V
ERSION=\"1.5\"  -Iinstgen/installer.inc /cygdrive/c/MozillaRoot/mozilla/browser/
installer/windows/$i > instgen/$i; \
done
/cygdrive/c/MozillaRoot/mozilla/config/preprocessor.pl: invalid argument: -svg
make[1]: *** [installer] Error 255
make[1]: Leaving directory `/cygdrive/c/mozillaroot/firefox/browser/installer/wi
ndows'
make: *** [installer] Error 2
make: Leaving directory `/cygdrive/c/mozillaroot/firefox/browser/installer'

Specifically, this line could the problem:
-DPKG_BASENAME=firefox-0.10.en-US.win32 -svg

Note the space before -svg

I use the following .mozconfig settings to turn on SVG, which worked up until today:

ac_add_options --enable-svg
ac_add_options --enable-svg-renderer-gdiplus
is this on the trunk?  the trunk filenames don't appear to have changed.
This is not on the trunk (neither is source l10n). That will merge later.
I fixed the SVG/GTK1 issues in package-name.mk version 1.1.2.2
Comment on attachment 157272 [details] [diff] [review]
Standardize naming

We're not getting any Mac trunk firefox nightlies because the configure.in and
autoconf.mk.in parts of this patch need to land on the trunk (probably
modified, due to recent --enable-application changes)
Attachment #167682 - Flags: review?(bryner) → review+
Component: Build Config → General
Product: Firefox → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: