666573 - Ship automated updates for contributed Linux64 release builds

Status: RESOLVED FIXED

(SeaMonkey :: Release Engineering, defect)

Description

[Sven Grull]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:7.0a1) Gecko/20110622 Firefox/7.0a1 SeaMonkey/2.4a1
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:7.0a1) Gecko/20110622 Firefox/7.0a1 SeaMonkey/2.4a1

Create partial updates for contributed Linux64 builds:

From the newsgroup, Callek:

"I think there should be a way to do that, and it is wanted by me at least.

I'd rather update users from an old security-hole build to a new 
fixed-build, even if BOTH builds are unsupported officially.

That said, I don't see an easy way in automation terms to do that [yet]."

Reproducible: Always

Comment 1

[Robert Kaiser]

First of all, let's not emphasize on if the updates are partial or complete, the main thing is that we ship updates through the AUS system at all.

I have thought about this a number of times as well, and I guess we should just try and get linux64 into the platforms we create updates for and then see how things go - we can't make it much worse there.

This will probably not be high priority, though, first we should get 2.2 to a state where we think it's shippable, and have MU available for the majority of our users.

Comment 2

[Robert Kaiser]

I've tried to work on this but unfortunately there's one thing that makes it hard, and that's our linux64 files being in a different location than those for other platforms - and that linux64 only has the en-US builds, no locales.

Comment 3

[Justin Wood (:Callek)]

(In reply to comment #2)
> I've tried to work on this but unfortunately there's one thing that makes it
> hard, and that's our linux64 files being in a different location than those
> for other platforms - and that linux64 only has the en-US builds, no locales.

On the one-hand we have linux_64 as part of the candidates dir stuff.

So the generation won't be too hard, we could start adding this to bouncer that should make the releases/ stuff a bit transparant.

The problem with current automation would come when we don't have the files mirrored, but at least some of the automation side "just works" though the final-place this goes is a problem.

Comment 4

[Robert Kaiser]

(In reply to comment #3)
> The problem with current automation would come when we don't have the files
> mirrored, but at least some of the automation side "just works" though the
> final-place this goes is a problem.

I think the paths at least in the verify config, maybe even the beta/final snippets are wrong, but I checked in the patches. If you see anything go wrong when running 2.2b3, feel free to back out, but note that the most important patch was the one in CVS.

The patches I pushed:
http://hg.mozilla.org/build/buildbot-configs/rev/03753389e06b
http://hg.mozilla.org/users/Callek_gmail.com/tools/rev/e4e92e4f4e98
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&subdir=mozilla/tools/patcher-configs&command=DIFF_FRAMESET&file=mozBeta-seamonkey-branch-patcher2.cfg&rev1=1.7&rev2=1.8&root=/cvsroot

Comment 5

[Robert Kaiser]

I created a complete update snippet for 2.0.13 to 2.0.14 for betatest and releastest channels, but for the latter, I felt better with actually copying the MAR to releases/ so I can only test it tomorrow or so.
If it works, we can copy those for all 2.0.x releases for beta and release channels so they all should get updated to 2.0.14.

Comment 6

[Robert Kaiser]

Just FYI, here are the total ADU numbers (from 2011-06-30) for all SeaMonkey releases on Linux64 per channel:

nightly	aurora	beta	release	default
24	1	13	247	556

Those on "default" probably have an installation from their distro.

On 2.1, we have ~85 ADU on the release channel, 2 on beta.
On 2.0.14, we have ~40 ADU on the release channel, ~110 on older 2.0.x versions, none before 2.0.3 though, and none on the beta channel.

Comment 7

[Robert Kaiser]

Oh, the query I used for that data was this one, just so I find it again when I need it:

select Crossjoin({[Products].[SeaMonkey].[Other]}, {[Channels].[nightly], [Channels].[aurora], [Channels].[beta], [Channels].[release], [Channels].[default]}) ON COLUMNS,
  NON EMPTY {([Date].[2011].[6].[15].[2011-06-15] : [Date].[2011].[7].[1].[2011-07-01])} ON ROWS
from [BlockList Analysis]
where [Build Target].[Linux_x86_64-gcc3]

Comment 8

[Robert Kaiser]

I have now put the manual snippets for 2.0.3-2.0.13 online that should update those to 2.0.14 (via complete MARs) - keeping the bug open for manually creating equivalent snippets for 2.1 users to update to 2.2 (no significant population was on 2.1 or 2.2 betas, last time I checked) and to do the same for MU from 2.0.14 to 2.2 later.

Comment 9

[Robert Kaiser]

I also have put manually created snippets online for 2.1a1-2.1 to update them to 2.2.

Comment 10

[Robert Kaiser]

FIXED as now snippets for the major update from 2.0.14 to 2.2 are online as well.

We'll need new bugs for every new release that's coming, as we'll need to continue to do all this manually.