Closed Bug 381172 Opened 15 years ago Closed 15 years ago

Generate beta snippets for earlier 2.0.0.4/1.5.0.12 RCs

Categories

(Release Engineering :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: nthomas, Unassigned)

Details

Attachments

(5 files)

We're currently at RC3 for Firefox 2.0.0.4, and RC2 for Firefox & Thunderbird 1.5.0.12. All three have live snippets on the betatest channel for prior releases, done the way they've always beeb done them (eg version is 2.0.0.4). 

This bug is about generating snippets for the earlier RCs of the new release, so that they can be offered on the beta channel ahead of the final release. It turns out patcher2 is not ready to handle this case, so some manual trickery is needed. Release drivers want to push on beta for all three apps/version combos.

Here's my plan for review (using specifics from 2.0.0.3):

1, Modify the patcher configs so that they have blocks in <current update> with
   <rc>
     beta 3
     betatest 3
   </rc>
   so that the beta snippets get a version like 2.0.0.4rc3.

2, Apply disable_complete_override.diff to patcher.pl (will attach this), so that we don't force a complete update from 2.0.0.3 -> 2.0.0.4 RC3

3, Backup/move aside the already generated snippets

4, Generate new snippets (based on the existing mar files)

5, Run the add_rcs.sh shell script (will attach), which copies files from 2.0.0.2 to each of the dirs corresponding to 2.0.0.4 RCs. It also adds update snippets for the Romanian locale (ro) which is new for 2.0.0.4

6, Do extensive diff checks to sanity check

7, Enable updates and run verification. Announce to QA.
The change is in the sub-routine CreatePartialPatchInfo
This file contains all the information for add_rcs.sh to use (paths, locales, hash & size info for ro etc).
Attachment #265274 - Attachment is patch: false
In lieu of disable_complete_override.diff, I'd like to make this a configurable option; this is something we're bound to run into more than just this go around (in fact, any time we release an rcN where N > 1 as the first RC we release).

Here's an (admittedly untested) attempt at that...
Attachment #265282 - Flags: review?(nrthomas)
Comment on attachment 265282 [details] [diff] [review]
My take on disabling the complete jump

Testing bot says - FAIL.

In hunk 3, use disableCompleteJumpForRcs instead of ..RCs

And I then get 
Can't use string ("1") as a HASH ref while "strict refs" in use at MozAUSConfig.pm line 658.
after setting this in the rc block
   DisableCompleteJump   1
Attachment #265282 - Flags: review?(nrthomas) → review-
Forgot to say that this works fine in my reduced-case test-setup, meaning that the partial snippet on beta* for the last release is actually a partial when DisableCompleteJump is 1, otherwise a complete. (I see problems with the releasetest partial snippet when the Disable is not set, which we'll need to fix elsewhere.)

Maybe we should rename this bug if we aren't going to provide updates from 1.5.0.12 RC1 and 2.0.0.4 RC1 & 2.
Comment on attachment 265550 [details] [diff] [review]
Improved patch to disable complete jump

Looks good... no violation of strict HASH refs here!! ;-)

Thanks for cleaning that up.
Attachment #265550 - Flags: review?(preed) → review+
(In reply to comment #8)
> (From update of attachment 265550 [details] [diff] [review])
> Looks good... no violation of strict HASH refs here!! ;-)
> 
> Thanks for cleaning that up.

Landed on trunk:
  mozilla/tools/patcher/MozAUSConfig.pm   1.11 	
  mozilla/tools/patcher/patcher2.pl       1.21
Status: NEW → RESOLVED
Closed: 15 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.