Closed Bug 388524 Opened 17 years ago Closed 16 years ago

Partial / Complete Updates on "Beta" Channel doesn't correctly handle rc2, rc3, ...

Categories

(Release Engineering :: General, defect, P3)

defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: cbook, Assigned: rhelmer)

References

Details

Attachments

(3 files, 1 obsolete file)

Currently 2.0.0.4 users should get partial updates to 2.0.0.5

When users are on the beta channel, they will only get served a complete update from 2.0.0.4 to 2.0.0.5 not the normal partial. 

This regressed between 2.0.0.4/2.0.0.5 since the update for 2.0.0.3->2.0.0.4 on the beta channel is partial.
Flags: blocking1.8.1.6?
Component: Software Update → Build & Release
Flags: blocking1.8.1.6?
Product: Firefox → mozilla.org
QA Contact: software.update → preed
Version: 2.0 Branch → other
The issue here is that DisableCompleteUpdateJump isn't set to 1 when the patcher config gets bumped.

The logic here works like:

if (rc == 1) {
  ... publish test snippets pointing to partial/complete mars as normal ...
} else (rc > 1) {
  ... publish test snippets as normal, but for rc1 builds, publish complete mars for both partials and complete, because we don't create mars from RC builds to RC builds.
}

This is just an oversight in the automation.
Blocks: 387970
Assignee: build → joduinn
Priority: P3 → P2
Havent been able to look at this, so returning it to the pool.
Assignee: joduinn → build
Priority: P2 → P3
We just hit this problem again with 2007rc2 on the beta channel. 

1) this problem only occurs on "beta" channel. It does not occur on "betatest" or "release" or "releasetest" channels

2) When doing "rc1", then the correct "partial updates from previous release" are pushed to the beta channel. 

3) When doing "rc2" or later, we should be doing the same. However, we instead push "full updates". The confusion here is that we correctly do not generate or distribute partial updates from rc1 -> rc2 -> rc3, etc. It seems like if people on "beta" are on previous release, then they should get a partial update? But if people on "beta" are on a previous rc of the current release, they should get a full update? Do we even support people on "beta" even using a previous rc of the current release?


Updated subject accordingly.
Summary: Only Complete Updates served for 2.0.0.4 Users on the "Beta" Channel → Partial / Complete Updates on "Beta" Channel doesnt correctly handle rc2, rc3, ...
4) If "betatest" and "beta" are supposed to be identical, how come this is only a problem with "beta", and not with "betatest"?
Summary: Partial / Complete Updates on "Beta" Channel doesnt correctly handle rc2, rc3, ... → Partial / Complete Updates on "Beta" Channel doesn't correctly handle rc2, rc3, ...
I see this during my update testing on Mac, going from 2.0.0.7->2.0.0.8rc2. I get the full update, and is pretty big on the mac.
Assignee: build → nobody
QA Contact: mozpreed → build
Assignee: nobody → rhelmer
Took a look through the code, DisableCompleteJump is expected in the channel section. It looks like testchannels are done totally differently, which is why betatest does not have this problem while beta does.
Attachment #300908 - Flags: review?(nrthomas)
Comment on attachment 300908 [details] [diff] [review]
disable complete jump should be in <rc> section

r+. Please fix the same problem in the Thunderbird config when you check in.
Attachment #300908 - Flags: review?(nrthomas) → review+
Checking in moz18-branch-patcher2.cfg;
/cvsroot/mozilla/tools/patcher-configs/moz18-branch-patcher2.cfg,v  <--  moz18-branch-patcher2.cfg
new revision: 1.4; previous revision: 1.3
done
Attachment #300908 - Attachment is obsolete: true
Ok, regenerating AUS config for 2.0.0.12, so we can stop tripping on this.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
PatcherConfig undid this change for rc4. Looks like this is the culprit:
http://mxr.mozilla.org/seamonkey/source/tools/release/Bootstrap/Step/PatcherConfig.pm#156
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #301143 - Flags: review?(nrthomas)
Comment on attachment 301143 [details] [diff] [review]
[checked in] oops i did it again

:-)
Attachment #301143 - Flags: review?(nrthomas) → review+
For some reason this feature is implemented as a "channel" in patcher. I supposed we could expand it to selectively jump certain RCs, but neither patcher nor Bootstrap::Step::PatcherConfig could handle that currently.

It only seems to matter that DisableCompleteJump "channel" is set to non-zero, so I think simply adding it to the RC channels will do the trick.
Attachment #301144 - Flags: review?(nrthomas)
Comment on attachment 301143 [details] [diff] [review]
[checked in] oops i did it again

Checking in moz18-branch-patcher2.cfg;
/cvsroot/mozilla/tools/patcher-configs/moz18-branch-patcher2.cfg,v  <--  moz18-branch-patcher2.cfg
new revision: 1.6; previous revision: 1.5
done
Attachment #301143 - Attachment description: oops i did it again → [checked in] oops i did it again
Attachment #301144 - Flags: review?(nrthomas) → review+
Comment on attachment 301144 [details] [diff] [review]
[checked in] more permanent fix

Checking in Bootstrap/Step/PatcherConfig.pm;
/cvsroot/mozilla/tools/release/Bootstrap/Step/PatcherConfig.pm,v  <--  PatcherConfig.pm
new revision: 1.15; previous revision: 1.14
done
Attachment #301144 - Attachment description: more permanent fix → [checked in] more permanent fix
Status: REOPENED → RESOLVED
Closed: 16 years ago16 years ago
Resolution: --- → FIXED
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: