407435 - Transition to new AUS channel names

Status: RESOLVED WONTFIX

(Release Engineering :: General, defect, P5)

Description

[J. Paul Reed [:preed]]

Filing this we can track change to the patcher config files, and the (now multiple) proposals regarding renaming AUS channels.

This was proposed by rhelmer on the release-drivers list:

I think we should stop using the "betatest" and "releasetest" channels. They confuse more than help when we hit beta periods, and they imply things that they should not (that "beta" == "ftp" and "release" == "mirrors").

For example, for a maintenance release we'd normally:

1) publish betatest channel, which points to ftp, test
2) publish beta channel, which points to ftp, test
3) after beta period, push release to mirrors.
4) publish releasetest channel, which points to mirrors, test
5) publish release channel, which points to mirrors

However this doesn't make as much sense for actual beta releases like 3.0b1; we still need step 1/2 but we skip step 3. Without making any changes, it'd make our workflow something like:

1) publish betatest channel, which points to ftp, test
2) push release to mirrors.
4) publish releasetest channel, which points to mirrors, test
5) publish beta channel, which points to mirrors

This is confusing, because we're assuming "beta/betatest" = "ftp" and "release/releasetest" = "mirrors". I also don't think our tools will support this out of the box, anyway.

So - I am proposing that we start transitioning to a new set of channels:

localtest, points to ftp
mirrortest, points to mirrors
beta, either points to ftp or mirrors
release, points to mirrors

QA would use "localtest" to test nightly/*-candidates builds, and "mirrortest" to test updates after the builds have been pushed to the mirrors but before the "release" channel has been turned on. Build group can ensure that "mirrortest" or "localtest" match "beta" or "release" as appropriate for the situation, before turning them on.

I'd like to do this for 3.0b2 if possible (not sure yet if it is), because we're going to have confusion over the channels and AFAICT build is going to have to hack stuff up in either case, we may as well opt for something that will reduce confusion.

dveditz also proposed:

While we're at it, can we kill "beta" too and call it the "prerelease"
channel instead (or "preview", "candidates" or something). When we switch
to post-release security updates this will make far more sense to people
than calling them "beta".

Comment 1

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Reassigning to correct component.

Comment 2

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

Triaged to Future.

Comment 3

[Chris Cooper [:coop] (he/him)]

Mass move of bugs from Release Engineering:Future -> Release Engineering. See
http://coop.deadsquid.com/2010/02/kiss-the-future-goodbye/ for more details.

Comment 4

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to comment #4)

> So - I am proposing that we start transitioning to a new set of channels:
> 
> localtest, points to ftp
> mirrortest, points to mirrors
> beta, either points to ftp or mirrors
> release, points to mirrors
> 
> QA would use "localtest" to test nightly/*-candidates builds, and "mirrortest"
> to test updates after the builds have been pushed to the mirrors but before the
> "release" channel has been turned on. Build group can ensure that "mirrortest"
> or "localtest" match "beta" or "release" as appropriate for the situation,
> before turning them on.
> 
> I'd like to do this for 3.0b2 if possible (not sure yet if it is), because
> we're going to have confusion over the channels and AFAICT build is going to
> have to hack stuff up in either case, we may as well opt for something that
> will reduce confusion.
> 
> dveditz also proposed:
> 
> While we're at it, can we kill "beta" too and call it the "prerelease"
> channel instead (or "preview", "candidates" or something). When we switch
> to post-release security updates this will make far more sense to people
> than calling them "beta".

This came up again today in context of FF3.7a4 release, where we make FF3.7a1/2/3/4 updates visible on the beta channel. 

localtest, points to ftp
mirrortest, points to mirrors
prerelease, either points to ftp or mirrors 
release, points to mirrors

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

I'll revisit the proposal above and see if QA is interested.

Comment 6

[Nick Thomas [:nthomas] (UTC+12)]

I failed to actually do comment #5, a-hem.

To restate the original proposal slightly, we'd end up with two common scenarios

Stable point release:
1) publish localtest channel, which points to ftp, test
2) publish beta channel, which points to ftp, test
3) after beta period, push files to mirrors
4) mirrortest channel available, which points to mirrors, test
   [was published at same time as 1), but non-functional]
5) publish release channel, which points to mirrors
localtest = beta; mirrortest = release; where '=' means the snippets do not differ at all. beta and release only differ by URLs to mar files.

Pre-RC development branch:
1) publish localtest channel, which points to ftp, test
2) push files to mirrors
3) mirrortest channel available, which points to mirrors, test
   [was published at same time as 1), but non-functional]
4) publish beta channel, which points to mirrors
mirrortest = beta. localtest only differs from mirrortest by URLs to mar files.

So localtest is a 'do updates work' channel for QA, and for a point release also a check that beta will work OK. In both cases mirrortest is used prior to shipping the largest chunk of end users for that branch.

Assuming we still want to do this then the work boils down to
* update existing patcher configs 
 * s/betatest/localtest/
 * s/releasetest/mirrortest/
 * set localtest to use ftp.m.o instead of stage-old.m.o to remove difference
   between localtest & beta for point release
* modify patcher-config-bump.pl, patcher-config-creator.pl, update-verify-bump.pl
  to support the above going forward
* testing of release automation for above changes
* move all existing betatest and releasetest dirs to new names in snippet store
* check for users on betatest who may be there for the latest and greatest, possibly provide a symlink betatest -> localtest on populated versions
* QA modify mozmill configs

That's kinda a sketch but shouldn't be far off. Unfortunately I won't have time to complete this, anyone else game ?

Comment 7

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

cc-ing al, juan (and tony) after our meeting with legneato.

Comment 8

[Samuel Sidler (:ss)]

(In reply to comment #7)
> cc-ing al, juan (and tony) after our meeting with legneato.

(fwiw, you didn't CC anyone because they were already CCed.)

Comment 9

[Nick Thomas [:nthomas] (UTC+12)]

No response from QA, so I'm assuming no longer any enthusiasm.

Comment 10

[Al Billings [:abillings - ex-MoCo]]

I hadn't even thought about it recently with everything else going on.

Comment 11

[[e-mail] (:bhearsum)]

For posterity, we are starting to rename channels under a fresh proposal in bug 986990. It only took 7 years!