Closed Bug 650933 Opened 14 years ago Closed 13 years ago

update verify bump scripts need to handle locales being dropped

Categories

(Release Engineering :: General, defect, P2)

x86
All
defect

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: armenzg, Assigned: rail)

References

Details

(Whiteboard: [releases][automation][l10n])

Attachments

(2 files)

These locales won't be shipped for Firefox 4 let's get rid of them.
Attached patch Patcher configs (deleted) — Splinter Review
Assignee: nobody → armenzg
Status: NEW → ASSIGNED
Attachment #526992 - Flags: review?(coop)
Attached patch Update verify config changes (deleted) — Splinter Review
Attachment #526993 - Flags: review?(coop)
Attachment #526992 - Flags: review?(coop) → review+
Attachment #526993 - Flags: review?(coop) → review+
Comment on attachment 526993 [details] [diff] [review]
Update verify config changes

http://hg.mozilla.org/build/tools/rev/fb335deb699b
Attachment #526993 - Flags: checked-in+
Comment on attachment 526992 [details] [diff] [review]
Patcher configs

coop or rail, could you please land this for me before generating the MUs?
Attachment #526992 - Flags: checked-in?
Comment on attachment 526992 [details] [diff] [review]
Patcher configs

Checking in moz191-branch-major-update-patcher2.cfg;
/cvsroot/mozilla/tools/patcher-configs/moz191-branch-major-update-patcher2.cfg,v  <--  moz191-branch-major-update-patcher2.cfg
new revision: 1.32; previous revision: 1.31
done
Checking in moz192-branch-major-update-patcher2.cfg;
/cvsroot/mozilla/tools/patcher-configs/moz192-branch-major-update-patcher2.cfg,v  <--  moz192-branch-major-update-patcher2.cfg
new revision: 1.5; previous revision: 1.4
done
Attachment #526992 - Flags: checked-in? → checked-in+
This is not my are of expertise.
Putting it back into the pool.
Assignee: armenzg → nobody
(In reply to comment #6)
> This is not my are of expertise.
> Putting it back into the pool.

Based on the patches being checked in, I'm not sure what is left to be done here, can you spell it out?
If I understand correctly, the bumper will recreate the locale list next time. MU bumper doesn't use old-shipped-locales, IIRC.
(In reply to comment #8)
> If I understand correctly, the bumper will recreate the locale list next
> time. MU bumper doesn't use old-shipped-locales, IIRC.

Hmm, it looks to me like it does:
perl ../tools/release/update-verify-bump.pl -o linux -p firefox -r Firefox --old-version=3.5.19 --old-app-version=3.5.19 --old-long-version=3.5.19 -v 4.0.1 --app-version=4.0.1 --long-version=4.0.1 -n 1 -a https://aus2.mozilla.org -s stage-old.mozilla.org -c ../tools/release/updates/moz191-firefox-linux-major.cfg -d /pub/mozilla.org/firefox/nightly/3.5.19-candidates/build2/ -l old-shipped-locales --pretty-candidates-dir --major

which is actually the problem, I think. This is actually describing the same issue from bug 384065 which was WONTFIX'ed because of cost/benefit of fixing the existing patcher scripts. Even in the AUS3 world we'll have to deal with the update verify bumper though.

One way to do this would be to have the bump script look at shipped-locales and old-shipped-locales, and only use locales listed in both.
Summary: Disable MU verification for as, ka & oc for Firefox 4 → update verify bump scripts need to handle locales being dropped
(In reply to comment #9)
> One way to do this would be to have the bump script look at shipped-locales
> and old-shipped-locales, and only use locales listed in both.

... and use this only for MUs. Usually oldVersion is stable enough to add/remove locales,so the possibility to hit bug 384065 is very low.
(In reply to comment #10)
> (In reply to comment #9)
> > One way to do this would be to have the bump script look at shipped-locales
> > and old-shipped-locales, and only use locales listed in both.
> 
> ... and use this only for MUs. Usually oldVersion is stable enough to
> add/remove locales,so the possibility to hit bug 384065 is very low.

Is there any reason we *can't* look at both of them for regular minor updates? It seems like there's no downside to doing so.
Betas may have a lot of add/removes, it's very rare when we drop/add locales for stable releases.
(In reply to comment #12)
> Betas may have a lot of add/removes, it's very rare when we drop/add locales
> for stable releases.

Yeah, I guess what I'm getting at is that we _can_ use the same code path for minor and major updates, even though it won't make a difference for minor updates, generally. Unless there's some reason it won't work for minor updates, why not use it for both?
Yeah, we can use the same code. 

Adding something like --all-locales which ignores old-shipped-locales and bumps configs the same way we have now may be an option and can be used for betas.
Assignee: nobody → rail
Priority: P3 → P2
Whiteboard: [releases][automation][l10n]
Fixed by bug 651481
Status: ASSIGNED → RESOLVED
Closed: 13 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: