If there are any reasons to not go ahead with this change, please reply
before the end of Friday PDT.
-Nick Thomas (RelEng)
Better would be say 2 days, but with some way to mark special builds
with 30 days (or more). I'm guessing: the try servers have two classes
1) "will this work on box other than the one I own?" 2days
2) "try this cool feature I think it kinda works" 30 days.
After two days the first class is forgotten or stale anyway.
(I'm interested in encouraging the second category, but if the time is
too short that use will not grow).
I don't think there is any need for the second category, if developers
want to make builds available for people to test they should be copying
them somewhere else. I tend to agree though that 14 days is probably
plenty, 7 days should be adequate I think. I'm betting the majority of
uses of TryServer are to check builds work and test ok now, so optimise
Worst case, you could probably file a ticket to get it copied to
stage. If that stops scaling, the people who hurt will be exactly the
people best able to write tools to automate or assist that process, so
I suspect it wouldn't be a long-term problem. :)
I realize this would complicate things, but having the 30 day builds
there can be useful... would it be possible to add a checkbox to let
users pick 30d or 14d (or even 1d) for the build TTL when they submit
the patch? It could default to 1d even, to reduce the demands even more.
Whatever solution we come up with here should also work for the hg
interface to the try server. Many people (me included) usually submit
try server patches by pushing to the try hg repository, so selecting a
retention period option may not be possible.
For now, we're going to reduce the time from 30 days to 14 days. Others
have suggested 2 or 7 days, but lets start with 14 for now. We can
revisit later, and see if we can reduce further. Please follow along in
If you need a specific try build to be preserved for longer then 14
days, please file a bug with mozilla.org/ReleaseEngineering, telling us
where you want your try build copied to. Be sure to specify exactly when
you did the try build, so we have enough time to move the build before
the 14 days are up.
I know its suboptimal to manually file a bug for this, and have us
manually copy files out like this. However, it feels rare enough that I
think we can all live with it for now. Also reducing TTL *now* will get
us out of our current current space situation, while we figure out what
if anything might be needed for longer-living try builds.
John J. Barton wrote:
> I guess that many developers don't have access to a server or that
> access is very painful.
I don't agree with that assertion. The majority of the people who can
use the try server can get an account on people.mozilla.org and transfer
builds there. As Shaver has suggested, we can create a space on ftp.m.o
for longer term hosting if people will need that instead.
I doubt this level of complexity is going to be worthwhile. If I was a
starting a build I'd probably play it safe and chose the 30 day option
just about every time. Mostly because you'd know if you want to keep
something after the build completes (based on test results etc) rather
If we have the mechanisms above for saving builds for longer periods
then it sounds like we should go ahead with the 14 day expiry.
How? Would that not still entail to first download it from try and then
upload it somewhere else (people or elsewhere)? For people outside Mozilla
Hq that will be painful. Unless there is some kind of shell access to try
that would let me directly copy it around.
> As Shaver has suggested, we can create a space on ftp.m.o
> for longer term hosting if people will need that instead.
> Mike Shaver wrote:
> > hg push ssh://hg.mozilla.org/try-14d
> > hg push ssh://hg.mozilla.org/try-30d
> > hg push ssh://hg.mozilla.org/try-1d (== /try)
> I doubt this level of complexity is going to be worthwhile. If I was a
> starting a build I'd probably play it safe and chose the 30 day option
> just about every time. Mostly because you'd know if you want to keep
> something after the build completes (based on test results etc) rather
> than before.
I don't agree. I was asked several times to put a more complex OS/2 patch
through the try server with the single reason to make sure that it builds
on the main platforms. I saw the same happen for quite a few other patches
for unusual configurations. For those I would surely not pick the 30 day
This was put in place on Thu April 9th.