Closed Bug 460247 Opened 13 years ago Closed 13 years ago

Update and move OS/2-specific README.txt files

Categories

(Firefox Build System :: General, defect)

x86
OS/2
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mozilla, Assigned: mozilla)

References

Details

(Keywords: fixed1.9.1)

Attachments

(2 files)

[I meant to file this a looong time ago...]

Currently, the README.txt files are located in en-US directories:

  mozilla-central browser/locales/en-US/os2/README.txt
  comm-central    suite/locales/en-US/installer/os2/README.txt
  comm-central    mail/locales/en-US/os2/README.txt

That means that after string freeze we cannot update the content any more. And that is exactly the time when bugs appear and we want to do that. (I forgot that once which caused a bit of a stir in Bug 429436...) As README.txt are not shipped with language packs, it also doesn't really make much sense for localizers to translate them.

So, I propose to move them somewhere else (very soon!), perhaps calling them README.os2 and then installing them by copying instead of $(INSTALL)ing, as originally suggested in bug 277488. What about moving them to

  mozilla-central browser/app/README.os2
  comm-central    suite/app/README.os2
  comm-central    mail/app/README.os2
Apparently there are no real localized releases for OS/2, why is that?

The Firefox file is actually translated for 

fr fy-NL gl ja-JP-mac ja nl pt-PT sq sr

CCing those localizers for input, too.
(In reply to comment #1)
> Apparently there are no real localized releases for OS/2, why is that?

We don't have resources to build (or repackage) and upload them. Plus, users haven't really requested it. They know to download en-US and install a langpack if they want their native language.

It's a pity to throw away already translated files, updating README.txt by hand every time I make an OS/2 puts a lot of effort on me.
> It's a pity to throw away already translated files, updating README.txt by hand
> every time I make an OS/2 puts a lot of effort on me.

I meant ... "_but_ updating README.txt by hand every time I make an OS/2 _release_ puts a lot of effort on me." And I should have added that I often forget to revise it at that point.


OK, so for the localizers it apparently doesn't matter too much. At least not enough to comment...

Gavin or Mike, KaiRo, Mark, would you be happy with the new locations I suggested in comment 0? Any better ideas? Who else should know about this?
Sounds OK to me.
The French team can actually see no problem for this move as this would only apply to a very tiny part of our users, so let it be.
Nonetheless, this could be part of the release note on the Web sites under a Contributed Builds > OS/2 section and that way could be updated at any moment.
I don't see why anything should be changed at all or what it should accomplish.
(In reply to comment #6)
> I don't see why anything should be changed at all or what it should accomplish.

It would allow the OS/2 maintainers freedom to update their readmes without affecting localizers, and would remove a burden on localizers to translate the file (even though most already don't).
1) Where does the README appear? If it's anywhere the normal user is supposed to read it, it should be localizable, or else I don't understand why we have L10n at all.
2) I don't feel good with populating app/ with something like this.
3) Why is OS/2 that much different from other OSes here? Just because someone else creates the builds?
1) It's not displayed as far as I know, just shipped in the app package.
2) app/ already contains Firefox's normal README. I suppose the equivalent for suite is just in the top level. I don't care that much where it lives, to be honest.
3) That, and it has its own README.
IMHO, the biggest point here is that in practice, nobody's creating l10n builds for OS/2, but folks just get language packs. Those language packs don't include the README, so, in practice, the README is already not localized as far as the user experience is concerned.

Yes, that's broken, but I don't intend to fix it, and apparently the OS/2 guys neither.
Gavin and Axel already addressed most points that I would have wanted to answer. A few more:

- As for why OS/2 is different, there is the point that it's a
  spare-time effort of very few people, and we just cannot keep up with
  what tens of developers do for the tier-1 platforms. That's why we are
  late and so often need to update the README late.

- We _could_ move the content of the three READMEs onto webpages somewhere
  (then probably below http://www.mozilla.org/ports/os2/ where us OS/2ers
  have write permission) and leave a stub README in their place pointing
  to those locations. But up to now the indications were that OS/2 users
  wanted a reference on their disk.

- To add it to the Contributed Builds -> OS/2 section of the release
  pages is a solution in between. But one where I am still likely to
  forget updating it with a new release (and in most cases actually need
  others to apply the changes which annoyingly delays the OS/2 release).
  So I actually like the in-repository or just-on-a-webpage options
  better.

- If we move it to somewhere else in the repos, I also don't care where
  in the tree it is. I just need to cp it to dist/bin at some point. The
  /app/ dirs were just my first thought.
OK, so if people don't like having this in the app/ dirs, then let's put it in widget/src/os2. This is the "most OS/2 only place" that I can think of and so shouldn't disturbe anyone else. As there isn't such a place in comm-central, we will have to move the files from comm-central:

      mozilla-central browser/locales/en-US/os2/README.txt
 --->                 widget/src/os2/README.firefox

      comm-central    suite/locales/en-US/installer/os2/README.txt
 ---> mozilla-central widget/src/os2/README.seamonkey

      comm-central    mail/locales/en-US/os2/README.txt
 ---> mozilla-central widget/src/os2/README.thunderbird

They would then be copied from their source name to $(DIST)/bin/README.txt when linking wdgtos2.dll, using MOZ_APP_NAME to copy the right one.

Any more objections to this?
Not sure how this blends with shredder and minefield.

I'm not the right guy to comment, though, the app directories are under the rule of a different mob.
(In reply to comment #13)
> Not sure how this blends with shredder and minefield.

That should be fine, they only have a different MOZ_APP_DISPLAYNAME.
OK, so this is the comm-central part of the os2/README.txt move. KaiRo, if you are OK with this, is the review from someone else still needed?

(In the next patch I'm going to add them to mozilla-central and then change the text afterwards to adapt the content to the current state.)
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Attachment #351074 - Flags: review?(kairo)
This seems to work for the mozilla-central part, just makefile changes, new and moved files.
Attachment #351078 - Flags: review?(ted.mielczarek)
Attachment #351074 - Flags: review?(kairo) → review+
Comment on attachment 351074 [details] [diff] [review]
remove OS/2 READMEs from comm-central [Checkin: Comment 18]

I still don't think it's a good idea but as you don't seem to be convinceable otherwise in any case and it's "your" port, let's just do it.
Comment on attachment 351074 [details] [diff] [review]
remove OS/2 READMEs from comm-central [Checkin: Comment 18]

Well, if there was a way to exempt all os2/README.txt files from string freezes, I would have been convinced immediately. ;-) As I didn't see anything like that, nor other workable alternatives I don't see what else we could do.

So, checked this into comm-central:
http://hg.mozilla.org/comm-central/rev/11ccc3c7f177
Attachment #351074 - Attachment description: remove OS/2 READMEs from comm-central → remove OS/2 READMEs from comm-central [Checkin: Comment 18]
Attachment #351078 - Flags: review?(ted.mielczarek) → review+
Comment on attachment 351078 [details] [diff] [review]
move OS/2 READMEs to widget/src/os2/ [Checkin: Comment 19]

http://hg.mozilla.org/mozilla-central/rev/4f38214f17c0

Pushed this one. Leaving open to finally make the doc changes in those files that I wanted to do for a while.
Attachment #351078 - Attachment description: move OS/2 READMEs to widget/src/os2/ → move OS/2 READMEs to widget/src/os2/ [Checkin: Comment 19]
(In reply to comment #19)
> (From update of attachment 351078 [details] [diff] [review])
> http://hg.mozilla.org/mozilla-central/rev/4f38214f17c0
> 
> Pushed this one. Leaving open to finally make the doc changes in those files
> that I wanted to do for a while.

I guess this should also go to the mozilla-1.9.1 branch as comm-central changed to pull from the mozilla-branch rather than from the trunk.

And a question, what happens when
>--- a/widget/src/os2/Makefile.in
>++ b/widget/src/os2/Makefile.in
>@@ -124,6 +124,9 @@
> 
> LOCAL_INCLUDES	= -I. -I$(srcdir)/../xpwidgets -I$(srcdir)
> 
>+libs::	README.$(MOZ_APP_NAME)
>+	cp -f $^ $(DIST)/bin/README.txt
>+
> export::
> 	test -d ./res || mkdir ./res
> 	test -f ./res/aliasb.ptr || cp $(srcdir)/res/*.* ./res

the readme.$(MOZ_APP_NAME) doesn't exist, means when you build xulrunner or sunbird?
(In reply to comment #20)
> (In reply to comment #19)
> > (From update of attachment 351078 [details] [diff] [review] [details])
> > http://hg.mozilla.org/mozilla-central/rev/4f38214f17c0
> > 
> > Pushed this one. Leaving open to finally make the doc changes in those files
> > that I wanted to do for a while.
> 
> I guess this should also go to the mozilla-1.9.1 branch as comm-central changed
> to pull from the mozilla-branch rather than from the trunk.

Sorry for the delay, I was away... Yes, we need it there, too.

Axel, any particular procedure to observe for this or is approval1.9.1 good enough to remove files from l10n?
For this one, regular tree rules are good enough.
Comment on attachment 351078 [details] [diff] [review]
move OS/2 READMEs to widget/src/os2/ [Checkin: Comment 19]

Changes that affect only OS/2 (but include modifications to one cross-platform file).
Attachment #351078 - Flags: approval1.9.1?
(In reply to comment #20)
> And a question, what happens when
> >+libs::	README.$(MOZ_APP_NAME)
> >+	cp -f $^ $(DIST)/bin/README.txt
> >+
> 
> the readme.$(MOZ_APP_NAME) doesn't exist, means when you build xulrunner or
> sunbird?

As the dependent file doesn't exist it won't copy any file. (I just confirmed that it doesn't stop the build by resetting the app name to firefoxXXX.)
Comment on attachment 351078 [details] [diff] [review]
move OS/2 READMEs to widget/src/os2/ [Checkin: Comment 19]

a191=beltzner
Attachment #351078 - Flags: approval1.9.1? → approval1.9.1+
Pushed attachment 351078 [details] [diff] [review] to mozilla-1.9.1:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/18aefb9b7345

This bug has become long enough. I'll do the actual updates of the README files in Bug 443112.
--> FIXED
Blocks: 443112
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Keywords: fixed1.9.1
Resolution: --- → FIXED
Blocks: 475120
No longer blocks: 475120
Depends on: 507251
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.