Bug submission policy
Gia Shervashidze
i need some [initial] help - full Georgian localized versions for
Mozilla "Full house" is ready for trunk & 1.8_BRANCH. To avoid mistake
like i already done just asking Your advices/recommendations for what
kind of bugs will be appropriate for reviewers in such case.
So, for now, i need submit some different bugs for CVS committing.
Would You be so kind to give me some corresponding "best fit" bugzilla
links and/or just clue me what kind of bugs must i submit for CVS commit
[for each one]? - Where (product/components), to whom, flags, etc.
0. Must i submit bugs separately for trunk and MOZILLA_1.8_BRANCH?
BUGS (planned)
1. Firefox - build goes smoothly - needs update/add/remove some files
for almost all modules (browser, toolkit, dom, security, etc.)
2. Thunderbird - builds with some errors for Linux & MAC and filed for
Win - needs update/add/remove some files from 'mail'
3. Calendar (Sunbird & Lightning) - files uploaded without bug
submission - must i fill separate bug for fix them "officially"?
4. Suite (only in trunk) - whole module (all files) must committed
5. Later i'd like to upload localized files (they are english now) from
".\updater" and ".\installer" folders for 'browser', 'calendar' and
'mail' _and_ to have possibility to restore them back if the build fails
(needs to watch tinderbox for about 3+3=6 hours to be sure they didn't
break the build, as seems localized updater.ini and possibly files from
"installer" does it for now)
i think these are [some of] main kind of bugs for localization and could
be useful for others also.
Thanks ahead,
g.\
Axel Hecht
> Hi all,
>
> i need some [initial] help - full Georgian localized versions for
> Mozilla "Full house" is ready for trunk & 1.8_BRANCH. To avoid mistake
> like i already done just asking Your advices/recommendations for what
> kind of bugs will be appropriate for reviewers in such case.
>
> So, for now, i need submit some different bugs for CVS committing.
> Would You be so kind to give me some corresponding "best fit" bugzilla
> links and/or just clue me what kind of bugs must i submit for CVS commit
> [for each one]? - Where (product/components), to whom, flags, etc.
>
> 0. Must i submit bugs separately for trunk and MOZILLA_1.8_BRANCH?
No, as of now, you don't need bugs to submit to the trunk.
It's probably a good idea to have meaningful check-in comments, that
describe your changes. A good example is what the French guys are doing,
see an example at http://l10n.mozilla.org/buildbot/changes/155.
For the MOZILLA_1_8_BRANCH, you should file bugs "per issue", the
granularity somewhat depends on the size of the patch, too. Those bugs
should be filed in your component, in the Mozilla Localizations product.
I have created http://wiki.mozilla.org/L10n:Teams:ka for you, and added
a bug-filing link.
> BUGS (planned)
> 1. Firefox - build goes smoothly - needs update/add/remove some files
> for almost all modules (browser, toolkit, dom, security, etc.)
That could be one bug, from what I recall. Make sure to use the English
updater.ini?
> 2. Thunderbird - builds with some errors for Linux & MAC and filed for
> Win - needs update/add/remove some files from 'mail'
One bug, too, probably. Those changes are on the trunk already, right?
Hrm. The language pack is likely not going to install in tb2 until
tb2.0.0.4 is out. Anyway, did you test those? Again, make sure that the
installer and updater stuff is on English when submitting a patch.
> 3. Calendar (Sunbird & Lightning) - files uploaded without bug
> submission - must i fill separate bug for fix them "officially"?
Calendar is still open. But that's really just calendar, that is,
changes that you want for calendar, but that are in toolkit or dom, need
bugs and approval for the branch.
> 4. Suite (only in trunk) - whole module (all files) must committed
Suite isn't really working yet, and would work only on the trunk. That's
open, but you should talk with Robert Kaiser on how useful that is already.
> 5. Later i'd like to upload localized files (they are english now) from
> ".\updater" and ".\installer" folders for 'browser', 'calendar' and
> 'mail' _and_ to have possibility to restore them back if the build fails
> (needs to watch tinderbox for about 3+3=6 hours to be sure they didn't
> break the build, as seems localized updater.ini and possibly files from
> "installer" does it for now)
>
> i think these are [some of] main kind of bugs for localization and could
> be useful for others also.
For each bug, please create a patch. You do that by editing your working
copy, build and test it locally, and then you would do a
cvs -z3 diff -u
in the place that is affected by the changes, for example, in the
l10n/ka/browser directory.
Redirect the output to a file, and
- Check that the diff actually shows the changes you intended to make.
These files look a tad cumbersome at first, but you'll get it quickly.
Lines starting with ' ' are context, lines with '-' are removed, lines
with '+' are added.
- Attach the file to the bug, and request approval1.8.1.5 by setting the
flag to '?'. That can be found in the details of the attachment.
In general, the current tree rules for the branch in question are on the
respective main l10n tinderbox, that is, in the case of the
MOZILLA_1_8_BRANCH,
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla1.8-l10n.
Hope that helps, and thanks for the detailed questions
Axel
Gia Shervashidze
> Gia Shervashidze wrote:
>> ...
>> 0. Must i submit bugs separately for trunk and MOZILLA_1.8_BRANCH?
>
> No, as of now, you don't need bugs to submit to the trunk.
Does it means that i can commit files for the Trunk (and/or open
branches) without permission?
> It's probably a good idea to have meaningful check-in comments, that
> describe your changes. A good example is what the French guys are doing,
> see an example at http://l10n.mozilla.org/buildbot/changes/155.
>
> For the MOZILLA_1_8_BRANCH, you should file bugs "per issue", the
> granularity somewhat depends on the size of the patch, too. Those bugs
> should be filed in your component, in the Mozilla Localizations product.
>
> I have created http://wiki.mozilla.org/L10n:Teams:ka for you, and added
> a bug-filing link.
Very helpful (especially to have dedicated place for bug submission)
>> BUGS (planned)
>> 1. Firefox - build goes smoothly - needs update/add/remove some files
>> for almost all modules (browser, toolkit, dom, security, etc.)
>
> That could be one bug, from what I recall. Make sure to use the English
> updater.ini?
>
>> 2. Thunderbird - builds with some errors for Linux & MAC and filed for
>> Win - needs update/add/remove some files from 'mail'
>
> One bug, too, probably. Those changes are on the trunk already, right?
> Hrm. The language pack is likely not going to install in tb2 until
> tb2.0.0.4 is out. Anyway, did you test those? Again, make sure that the
> installer and updater stuff is on English when submitting a patch.
ok, i see, 'll start with 2nd
>> 3. Calendar (Sunbird & Lightning) - files uploaded without bug
>> submission - must i fill separate bug for fix them "officially"?
>
> Calendar is still open. But that's really just calendar, that is,
> changes that you want for calendar, but that are in toolkit or dom, need
> bugs and approval for the branch.
ok, could "calendar guys" clue me some best practice?
>> 4. Suite (only in trunk) - whole module (all files) must committed
>
> Suite isn't really working yet, and would work only on the trunk. That's
> open, but you should talk with Robert Kaiser on how useful that is already.
ok
Helpful indeed
Thanks, Pike
g.\
Robert Kaiser
> Axel Hecht იწერება:
>> No, as of now, you don't need bugs to submit to the trunk.
>
> Does it means that i can commit files for the Trunk (and/or open
> branches) without permission?
Yes - as long as they are in the areas you own (i.e. your localization).
Robert Kaiser
Stephen Holt
I'm writing to enquire about the progress of my request for CVS access
for the Kinyarwanda localization team (Bug 370617). As of February, the
work had been QAd and the SSH form had been received, but since then
there has been no progress.
Regards,
Steve.
___________________________________________________________
Yahoo! Answers - Got a question? Someone out there knows the answer. Try it
now.
http://uk.answers.yahoo.com/
Stefan Sitter
>>> 3. Calendar (Sunbird & Lightning) - files uploaded without
>>> bug submission - must i fill separate bug for fix them
>>> "officially"?
>> Calendar is still open. But that's really just calendar, that
>> is, changes that you want for calendar, but that are in toolkit
>> or dom, need bugs and approval for the branch.
> ok, could "calendar guys" clue me some best practice?
Open means that no approval is required to check in changes to
MOZILLA_1_8_BRANCH in l10n/ka/calendar/ and
l10n/ka/other-licenses/branding/sunbird. But if you need a change
for Sunbird e.g. in l10n/ka/toolkit you need to file a bug and
request approval.
If all files are available for Sunbird/Lightning I'd recommend to
file a bug (Product: Calendar) to add ka to
mozilla/calendar/locales/all-locales. This would give you Sunbird
nightly builds and compare-locale results on
[http://tinderbox.mozilla.org/Mozilla1.8-l10n-ka/].
/Stefan
Simon Paquet
>>> 3. Calendar (Sunbird & Lightning) - files uploaded without bug
>>> submission - must i fill separate bug for fix them "officially"?
>>
>> Calendar is still open. But that's really just calendar, that is,
>> changes that you want for calendar, but that are in toolkit or dom, need
>> bugs and approval for the branch.
>
>ok, could "calendar guys" clue me some best practice?
We would like to see you filing a bug at least for major changes, that
you commit to the tree, e.g. a whole new dialog is added by the Calendar
developers and you commit the initial translation of the dialog-strings.
For calendar you should also watch the calend...@mozilla.bugs mail
alias, which the developers use to alert localizers of issues, which may
have an impact on their localizations.
At the moment Calendar has a full 1.8 branch and trunk sync policy,
meaning that the trunk and the 1.8 branch should be kept in sync at all
times for code/strings relating to Calendar products.
You should take a look at cross-commit
<http://developer.mozilla.org/en/docs/Using_cross_commit> and make
yourself acquainted with that, as it will make your life easier.
Please also watch this newsgroup and the calendar development blog
<http://weblogs.mozillazine.org/calendar>, so that you are aware of all
Calendar-related events that may concern localizers.
Cya
Simon
--
Calendar l10n coordinator
Calendar Website Maintainer: http://www.mozilla.org/projects/calendar
Calendar developer blog: http://weblogs.mozillazine.org/calendar
Gia Shervashidze
Thanks Robert,
At last i got "green bar" for trunk
g.\
P.S. ka (Georgian) suite files committed for trunk
Gia Shervashidze
...
> If all files are available for Sunbird/Lightning I'd recommend to
> file a bug (Product: Calendar) to add ka to
> mozilla/calendar/locales/all-locales. This would give you Sunbird
> nightly builds and compare-locale results on
> [http://tinderbox.mozilla.org/Mozilla1.8-l10n-ka/].
>
> /Stefan
Thanks Stefan,
Done, i hope Georgian Calendar [could be] on the right way now.
g.\
Gia Shervashidze
Simon Paquet იწერება:
> And on the seventh day Gia Shervashidze spoke:
:)
6 days to work, 7th day - to talk :)
time, time, time...
Bug submitted:
https://bugzilla.mozilla.org/show_bug.cgi?id=385341
Thanks for info,
g.\