L10n repackages being driven by buildbot
armenzg
tinderbox
The old tinderbox driven repackages are still being run but will be
turned off at some point if there are no problems on the new buildbot
way
Please let me know if there are any issues
Read more about it:
http://armenzg.blogspot.com/2008/09/l10n-build-changes.html
Seth Bindernagel
I also blogged about it here:
http://blog.mozilla.com/seth/2008/09/30/changes-to-the-l10n-build-system/
Thanks, Armen! Great work on the l10n-build infrastructure. We greatly appreciate your help.
-Seth
----- "armenzg" <arm...@gmail.com> wrote:
> _______________________________________________
> dev-l10n mailing list
> dev-...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-l10n
Rimas Kudelis
Hi Armen,
You said the header of the columns will change to
"platform_l10n_nightly". Why isn't there any reference to Firefox in
those headers? What will happen when Thunderbird, Suite or Calendar will
switch to the same repackaging scheme?
RQ
armenzg
I believe they are alreadry driving those by buildbot (not 100% sure)
but the headers can be changed easily
I will take note and tackle at some point
Thanks!
Axel Hecht
>>
>>> The L10n build repackages are being driven by buildbot rather than
>>> tinderbox
>>> The old tinderbox driven repackages are still being run but will be
>>> turned off at some point if there are no problems on the new buildbot
>>> way
>>> Please let me know if there are any issues
>>> Read more about it:
>>> http://armenzg.blogspot.com/2008/09/l10n-build-changes.html
>> Hi Armen,
>>
>> You said the header of the columns will change to
>> "platform_l10n_nightly". Why isn't there any reference to Firefox in
>> those headers? What will happen when Thunderbird, Suite or Calendar will
>> switch to the same repackaging scheme?
>>
>> RQ
>
> I believe they are alreadry driving those by buildbot (not 100% sure)
> but the headers can be changed easily
> I will take note and tackle at some point
We should use some common forward looking scheme for the tinderbox
column names.
:bs uses "mozilla-central-%platform"
comm central use "%long_platform comm-central l10n %brandshortname"
sunbird uses something totally odd
fx3.0.x uses "%platformish_l10n_nightly"
That's rather confusing. For ordering purposes, we should probably
favour something that brings all platforms for one app together.
I'd suggest something like
"%app %repo %platform"
where app could be one of firefox, thunderbird, seamonkey,
repo one of mozilla-central, comm-central, cvs-1.9.0,
platform one of win32, mac, linux-i686 (taken from ftp release dirs)
Axel
Rimas Kudelis
That would be great. And if the columns would then actually be sorted,
it would be even greater. :)
RQ
Mark Banner
> We should use some common forward looking scheme for the tinderbox
> column names.
>
> :bs uses "mozilla-central-%platform"
> comm central use "%long_platform comm-central l10n %brandshortname"
> sunbird uses something totally odd
> fx3.0.x uses "%platformish_l10n_nightly"
>
> That's rather confusing. For ordering purposes, we should probably
> favour something that brings all platforms for one app together.
>
> I'd suggest something like
>
> "%app %repo %platform"
>
> where app could be one of firefox, thunderbird, seamonkey,
> repo one of mozilla-central, comm-central, cvs-1.9.0,
> platform one of win32, mac, linux-i686 (taken from ftp release dirs)
IMHO app is only needed where more than one project is reporting to a
single tinderbox tree.
The advantage with putting platform first is that all the boxes from the
same platform get grouped together. This makes it easier to know what
you're looking at - though allowing sorting could improve this.
The problem with Firefox boxes is they tend to like to include the
actual name of the server - presumably so their IT guys can locate them
quickly.
We could probably also do things to shorten the name e.g. m-c instead of
mozilla-central.
The simpler and shorter the better I think.
Standard8
Axel Hecht
> On 2/10/08 14:55, Axel Hecht wrote:
>> We should use some common forward looking scheme for the tinderbox
>> column names.
>>
>> :bs uses "mozilla-central-%platform"
>> comm central use "%long_platform comm-central l10n %brandshortname"
>> sunbird uses something totally odd
>> fx3.0.x uses "%platformish_l10n_nightly"
>>
>> That's rather confusing. For ordering purposes, we should probably
>> favour something that brings all platforms for one app together.
>>
>> I'd suggest something like
>>
>> "%app %repo %platform"
>>
>> where app could be one of firefox, thunderbird, seamonkey,
>> repo one of mozilla-central, comm-central, cvs-1.9.0,
>> platform one of win32, mac, linux-i686 (taken from ftp release dirs)
>
> IMHO app is only needed where more than one project is reporting to a
> single tinderbox tree.
>
> The advantage with putting platform first is that all the boxes from the
> same platform get grouped together. This makes it easier to know what
> you're looking at - though allowing sorting could improve this.
What questions do you have at tinderbox? I would think that folks would
rather look at "How's Firefox doing?" than "How are my Windows builds?"
> The problem with Firefox boxes is they tend to like to include the
> actual name of the server - presumably so their IT guys can locate them
> quickly.
That only really matters if you're running the builds on multiple
slaves. Disambiguating that might be useful for Mozilla-l10n, I don't
think this adds value to Mozilla-l10n-ab-CD. Seems like using a trailing
slavename for the main tree could be a good idea.
> We could probably also do things to shorten the name e.g. m-c instead of
> mozilla-central.
>
> The simpler and shorter the better I think.
As long as the headers wrap nicely, I don't see a value in doing
abbreviations. This just leads to more stuff to explain to new
localizers. The same comment holds for dropping the app name. I'd prefer
consistency over shortness.
Axel
Rimas Kudelis
2008.10.03 11:05, Mark Banner raļæ½ļæ½:
> On 2/10/08 14:55, Axel Hecht wrote:
>> We should use some common forward looking scheme for the tinderbox
>> column names.
>>
>> :bs uses "mozilla-central-%platform"
>> comm central use "%long_platform comm-central l10n %brandshortname"
>> sunbird uses something totally odd
>> fx3.0.x uses "%platformish_l10n_nightly"
>>
>> That's rather confusing. For ordering purposes, we should probably
>> favour something that brings all platforms for one app together.
>>
>> I'd suggest something like
>>
>> "%app %repo %platform"
>>
>> where app could be one of firefox, thunderbird, seamonkey,
>> repo one of mozilla-central, comm-central, cvs-1.9.0,
>> platform one of win32, mac, linux-i686 (taken from ftp release dirs)
>
> IMHO app is only needed where more than one project is reporting to a
> single tinderbox tree.
>
> The advantage with putting platform first is that all the boxes from the
> same platform get grouped together. This makes it easier to know what
> you're looking at - though allowing sorting could improve this.
I don't know how others feel about it, but I personally prefer as many
l10n tinderboxes as possible to report to the same tree, as can be seen
here:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla-l10n-lt&hours=24 ,
because I really want to minimize the number of browser tabs required to
track my Mozilla localization.
This way I would have ONE place to check out and see how my locale
builds are doing, not two or five places.
For a similar reason I think that grouping by app is better, because I
would see all Firefox tinderboxes next to each other, then all
Thunderbird tinderboxes etc. Platform-specific issues aren't too common,
at least as far as l10n is concerned.
So, I totally agree with Axel's proposal of "%app %repo %platform".
> The problem with Firefox boxes is they tend to like to include the
> actual name of the server - presumably so their IT guys can locate them
> quickly.
If IT guys really want, they could append server name to the column
header... Unless this would cause a mess with multiple columns appearing
with the same "%app %repo %platform" combination...
> We could probably also do things to shorten the name e.g. m-c instead of
> mozilla-central.
>
> The simpler and shorter the better I think.
Agreed.
BTW, one more thing about Tinderboxes: I've noticed that "Breaf logs"
aren't at all brief (at least for SeaMonkey and Thunderbird). Can't we
have only the actual ERRORS in these logs? Even searching for the string
"error" is painful in the current logs, because there are lots of files
with this string in their names.
RQ
Mark Banner
>> The advantage with putting platform first is that all the boxes from the
>> same platform get grouped together. This makes it easier to know what
>> you're looking at - though allowing sorting could improve this.
>
>
> I don't know how others feel about it, but I personally prefer as many
> l10n tinderboxes as possible to report to the same tree, as can be seen
> here:
> http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla-l10n-lt&hours=24 ,
> because I really want to minimize the number of browser tabs required to
> track my Mozilla localization.
>
> This way I would have ONE place to check out and see how my locale
> builds are doing, not two or five places.
>
> For a similar reason I think that grouping by app is better, because I
> would see all Firefox tinderboxes next to each other, then all
> Thunderbird tinderboxes etc. Platform-specific issues aren't too common,
> at least as far as l10n is concerned.
>
> So, I totally agree with Axel's proposal of "%app %repo %platform".
So actually there are two use-cases here. One is the l10n trees and
other combined trees, where %app is probably better, the second is the
normal development trees e.g. http://tinderbox.mozilla.org/Thunderbird/
So I would adjust the proposal to:
"[%app] %platform %repo [%type]"
where [ ] signifies optional fields depending on which tree the
tinderbox is reporting to. E.g. for Thunderbird there's no point in
saying again that its a Thunderbird tinderbox.
The type field is also important on the main development trees as that
tells us what the box is actually doing.
Standard8
Axel Hecht
> On 2/10/08 14:55, Axel Hecht wrote:
>> We should use some common forward looking scheme for the tinderbox
>> column names.
>>
>> :bs uses "mozilla-central-%platform"
>> comm central use "%long_platform comm-central l10n %brandshortname"
>> sunbird uses something totally odd
>> fx3.0.x uses "%platformish_l10n_nightly"
>>
>> That's rather confusing. For ordering purposes, we should probably
>> favour something that brings all platforms for one app together.
>>
>> I'd suggest something like
>>
>> "%app %repo %platform"
>>
>> where app could be one of firefox, thunderbird, seamonkey,
>> repo one of mozilla-central, comm-central, cvs-1.9.0,
>> platform one of win32, mac, linux-i686 (taken from ftp release dirs)
>
> IMHO app is only needed where more than one project is reporting to a
> single tinderbox tree.
>
> The advantage with putting platform first is that all the boxes from the
> same platform get grouped together. This makes it easier to know what
> you're looking at - though allowing sorting could improve this.
What questions do you have at tinderbox? I would think that folks would
rather look at "How's Firefox doing?" than "How are my Windows builds?"
> The problem with Firefox boxes is they tend to like to include the
> actual name of the server - presumably so their IT guys can locate them
> quickly.
That only really matters if you're running the builds on multiple
slaves. Disambiguating that might be useful for Mozilla-l10n, I don't
think this adds value to Mozilla-l10n-ab-CD. Seems like using a trailing
slavename for the main tree could be a good idea.
> We could probably also do things to shorten the name e.g. m-c instead of
> mozilla-central.
>
> The simpler and shorter the better I think.
As long as the headers wrap nicely, I don't see a value in doing
Rimas Kudelis
Sure. I was talking about l10n tinderboxes, from a localizers perspective.
RQ
Nick Thomas
> I'd suggest something like
>
> "%app %repo %platform"
>
> where app could be one of firefox, thunderbird, seamonkey,
> repo one of mozilla-central, comm-central, cvs-1.9.0,
> platform one of win32, mac, linux-i686 (taken from ftp release dirs)
>
> Axel
This is now live for the Firefox 3.0 builds, which changed from
linux_l10n_nightly ---> Firefox cvs-1.9.0 linux-i686
for example. Those builds will be down for a bit, bug 467196.
And also for the mozilla-central builders
mozilla-central-linux ---> Firefox mozilla-central linux
-Nick
PS: No, I don't care about linux-i686 vs linux.