More Tbox changes on the way, most hitting on Friday
J. Paul Reed
My spree of killing old Tinderboxen continues:
1. argo has been supplanted by argo-vm; bl-bldlnx01 is now testing
builds from argo-vm. argo-vm is now pushing nightly builds and updates.
2. prometheus-vm builds of the trunk will be turned off on Wednesday (If
anyone can tell me why we're doing two linux builds of trunk, and
there's a reason for prometheus-vm to be doing one, let me know).
3. rhelmer worked with mscott to make tb-win32-tbox, a VC8 machine, the
trunk win32 nightly build machine.
4. Now that we have perf data from argo, btek will be retired on Friday.
5. Today, fx-win32-tbox will become the nightly Win32 trunk Tinderbox;
nightly builds will come from there.
5. On Friday gaius-vm will be retired, and all nightly Win32 trunk
builds will come from fx-win32-tbox.
Whew. I think that's all of them for this round.
If any of these changes will affect you negatively, please let me know.
Later,
preed
--
J. Paul Reed
Build/Release Engineer - The Mozilla Corporation
smtp://pr...@mozilla.com
irc://irc.mozilla.org/preed
pots://650.903.0800/x256
Boris Zbarsky
> 2. prometheus-vm builds of the trunk will be turned off on Wednesday (If
> anyone can tell me why we're doing two linux builds of trunk
Better coverage if they're out of phase comes to mind. In fact, this is
generally an argument for more tinderboxen, even identical ones. ;) Well, that
plus ideally we would be running the performance tests on multiple machines so
that we have a control in case of localized weirdness on a single testing machine.
All that said, prometheus-vm is the unique Firefox tinderbox running codesize
tests. While that situation persists, it shouldn't go away.
-Boris
J. Paul Reed
> J. Paul Reed wrote:
>> 2. prometheus-vm builds of the trunk will be turned off on Wednesday
>> (If anyone can tell me why we're doing two linux builds of trunk
>
> Better coverage if they're out of phase comes to mind. In fact, this is
> generally an argument for more tinderboxen, even identical ones. ;)
We've been trying to move towards Tinderboxen doing only singular sets
of builds, where possible, so coverage is constant. Secondarily, we've
been trying to make cycle times as fast as possible, once we have
constant coverage.
In this case, I'm not sure the cycles tell you exactly what you want,
since those two tinderboxen are not identical (this is the part where I
play the broken record about reference platforms), so really, you're
only getting integration coverage, which may or may not be useful if
prometheus-vm is using a different (older?) compiler than what's used
for nightlies.
Interestingly enough, it looks like prometheus-vm has a newer compiler,
so they're definitely not identical.
> Well, that plus ideally we would be running the performance tests on
> multiple machines so that we have a control in case of localized
> weirdness on a single testing machine.
Agreed, but again, that's where multiple instances of testing
tinderboxen come in. The plan is to utilize the hardware that was gaius,
prometheus, argo for this purpose.
> All that said, prometheus-vm is the unique Firefox tinderbox running
> codesize tests. While that situation persists, it shouldn't go away.
prometheus-vm is the 1.8 branch's linux box, and they're currently
waiting for 50 minutes for a cycle (as are people who are working on the
trunk).
I'll see how much work it is to get the codesighs tests running on
argo, so prometheus-vm can focus its duties on the 1.8 branch.
Later,
preed
Boris Zbarsky
> In this case, I'm not sure the cycles tell you exactly what you want,
> since those two tinderboxen are not identical
That's fine. I happen to think we should be testing performance in a big of a
variety of configurations corresponding to common user setups.
That's on the testing machine, of course. We do want our perf tests to be
running on identical builds.
Not to mention that more tinderboxen generally means knowing when the red is
gone away faster... And here we may indeed want multiple different compilers.
All of which is general considerations; I have no yen for prometheus-vm in
particular.
> Agreed, but again, that's where multiple instances of testing
> tinderboxen come in.
Ah, excellent. That addresses my concerns about perf tests in different
configurations nicely!
> I'll see how much work it is to get the codesighs tests running on
> argo, so prometheus-vm can focus its duties on the 1.8 branch.
Sounds great!
-Boris
J. Paul Reed
> Ah, excellent. That addresses my concerns about perf tests in different
> configurations nicely!
Yeah, the real focus for us right now is to get the build Tinderbox
situation figured out (so, ref platforms, stable VMs, VMs with enough
CPU, so cycle times are reasonable, etc.), and then take the freed-up
hardware that we have and use it for beefing up testing Tinderboxen.
We'll really start to hit this the beginning of next year, I think, so
we'll have to sit down and make sure we get testing data that's usefulf
for you, and other segments of the community who may be interested in
the data you are, or in other data.
>> I'll see how much work it is to get the codesighs tests running on
>> argo, so prometheus-vm can focus its duties on the 1.8 branch.
>
> Sounds great!
This is up and running, so we'll let the numbers shake out this week,
and switch prometheus-vm to building 1.8-only on Friday.