Sparky AND comet going away on Friday
J. Paul Reed
Hey all:
After some discussion in #build, it looks like comet is doing SeaMonkey
Trunk gtk1 builds, which I'm told is completely unsupported (i.e. gtk1
on Trunk).
So, it seems comet, in addition to Sparky, has outlived its usefulness.
I'm going to lay it to rest on Friday, unless someone screams real loud.
(If it looks like I'm going on a kick to kill old machines, that's
exactly what I'm doing.
I'm starting with the old, desktop-class hardware sitting in the office
[some of which won't boot if they're in a certain position, because the
hard drive is so old], and also going for low-hanging VMs, whose cycles
would be better used building modern products with modern settings.
Expect more of these messages in the coming weeks. The goal is not to
remove builds that really are needed, bu rather to get everyone on
supported [hardware support contract, RAID, known reference platforms,
etc.] build infrastructure.)
Thanks!
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
Robert Kaiser
> After some discussion in #build, it looks like comet is doing SeaMonkey
> Trunk gtk1 builds, which I'm told is completely unsupported (i.e. gtk1
> on Trunk).
Both btek and comet are doing gtk1 builds, comet is also uploading them
as nightlies.
The good thing with those two boxes is that those are among the
fastest-cycling tinderboxen we have on any tree atm, from what I see, so
they are quite fast to detect general fires on our tree.
BTW, luna is building gtk1 as well, AFAIK, but it's useful for the
bigger amount of tests it runs, esp. Z/mZ/Tdhtml.
It may be a good idea to replace that with a box runninjg only the tests
on builds from the official nightly machine - I think that is an
infrastructure you're working on, right?
And then, there's lhasa, which is doing GTK2 nightlies, I think is on a
VM nowadays and therefore quite fast as well, but still building
non-cairo gfx and not even canvas or SVG. We should really get some box
running on top of a more modern platform, that can actually build all of
those, ideally it should run on the Linux reference platform (of that
exists already).
I think the non-Linux SeaMonkey tinderboxen are in a better shape though
now, esp. once we resolve the VC8 issue (thanks to your team and esp.
coop for helping us with that).
Robert Kaiser
J. Paul Reed
> Hi preed,
>
>> After some discussion in #build, it looks like comet is doing
>> SeaMonkey Trunk gtk1 builds, which I'm told is completely unsupported
>> (i.e. gtk1 on Trunk).
>
> Both btek and comet are doing gtk1 builds, comet is also uploading them
> as nightlies.
> The good thing with those two boxes is that those are among the
> fastest-cycling tinderboxen we have on any tree atm, from what I see, so
> they are quite fast to detect general fires on our tree.
Kairo:
Thanks for the [historical] info; it helps a lot.
I'm reading this as we can still take comet and sparky down, correct?
gtk1 is unsupported on trunk, so I confused as to why we're building it.
Boris Zbarsky
> gtk1 is unsupported on trunk, so I confused as to why we're building it.
For the same reason that every single Linux Seamonkey tinderbox on trunk is
building unsupported configurations -- because the requests to change them to
build supported ones get, "That would require an OS upgrade" as a response...
-Boris
J. Paul Reed
Sure... and that's a related (but separate) issue.
My takeaway from the post was: gtk1--unsupported on the trunk--is being
built, not on one machine, not on two machines, but on three machines.
These machines are old, and from a hardware perspective, unstable. btek,
for instance, will not boot unless it's tipped on its side. They are
sitting in the office machine room, which does not have redundant power,
and has to go through a number of hoops to report into infrastructure
that lives at the colo.
I'm trying to optimize for two things:
1. Getting us to not rely on hardware that you have to have in a certain
position for it to boot.
2. Getting us to use standard, *known* configurations, i.e. ref
platforms, for every single product we build nightlies for.
The standard ref platform for Linux has mostly (I think?) been defined
for the trunk; bsmedberg has done a lot of work on that. I can dig up
the wiki page if you want to look at the specs.
The response (I'm assuming you mean from the "Build Team") isn't "That
would require an OS upgrade." While taht's true, what we're trying to
work towards, is "Put your Tinderboxen on hardware that have support
contracts, and use *known* compilers in specified configurations, that
all of the (hundreds?) of developers have input into, so we sort of know
that the features they need are included in the toolchain we use."
In another forum, you said you really only care about reliable test
data. You can't get reliable test data if you don't know, keep track of,
and control and/or monitor changes to your build configuration.
We have the same goals, but we're just looking at the problem from
different angles, I think.
Boris Zbarsky
> These machines are old, and from a hardware perspective, unstable.
Yes, I realize all that. ;)
> 1. Getting us to not rely on hardware that you have to have in a certain
> position for it to boot.
>
> 2. Getting us to use standard, *known* configurations, i.e. ref
> platforms, for every single product we build nightlies for.
Amen to both.
> In another forum, you said you really only care about reliable test
> data.
In the context of btek, sure. Outside of that context I also care about
coverage of our various apps on our various platforms, etc.
> We have the same goals, but we're just looking at the problem from
> different angles, I think.
I'm not even sure it's different angles. Just different priorities... I
personally am a lot more interested in better perf tests on trunk than in
anything involving any of the branches. But I realize that's not a useful
approach for us as an organization.
I do wish the branches would stop sucking up resources quite as much as they
tend to. :(
We sure do have the same goals, though. :)
-Boris
Robert Kaiser
> Thanks for the [historical] info; it helps a lot.
Good, I hoped it would help a bit to see through the jungle and gets us
all where we want to be. :)
> I'm reading this as we can still take comet and sparky down, correct?
> gtk1 is unsupported on trunk, so I confused as to why we're building it.
I think we can take all those down in principle, yes - we should take
down the other gtk1 boxes as well, though, in this case and hopefully
get up good gtk2 boxes to take over their job.
Esp. your info about btek being the one with harddisk problems gives me
some info about why it has been that flaky with certain config changes,
also that help a lot in understanding problem we've seen in the past.
Robert Kaiser
Neil
> gtk1 is unsupported on trunk, so I confused as to why we're building it.
Out of interest, there are branch gtk1 tinderboxen?
--
Warning: May contain traces of nuts.