Ship automated updates for contributed Linux64 release builds

RESOLVED FIXED

Status

SeaMonkey
Release Engineering
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Sven Grull, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

7 years ago
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
(Reporter)

Updated

7 years ago
Hardware: x86 → x86_64

Comment 1

7 years ago
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Create partial updates for contributed Linux64 release builds → Ship automated updates for contributed Linux64 release builds

Comment 2

7 years ago
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.
(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

7 years ago
(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

7 years ago
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

7 years ago
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

7 years ago
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

7 years ago
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

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

Comment 10

7 years ago
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.
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.