850224 - document standard operating procedures for releases

Status: RESOLVED FIXED

(Release Engineering :: Release Automation: Other, defect)

Description

[[e-mail] (:bhearsum)]

Nick and I were chatting yesterday about some of the confusion and mistakes that happened around the 19.0.2 release. A few of them revolved around the wrong thing being done for a chemspill. Eg, creating a l10n milestone. We should document these sorts of things somewhere. We were thinking that it would be best to put them inline in ship it, to keep the documentation as close as possible to the code.

As an example, "dashboard check" needs a wordy version of:
* For Betas, enabled
* For Releases, disabled
* For ESRs, disabled

Comment 1

[Chris AtLee [:catlee]]

The "submit_release" page (https://ship-it.mozilla.org/submit_release.html) needs to have some text near the "Partial versions" text box that clearly indicates that:
* you MUST include version N-1 in the partial versions
* you SHOULD NOT specify more than 3 partial versions

Comment 2

[[e-mail] (:bhearsum)]

I'm going to take care of this once the UI overhaul is done.

Comment 3

[[e-mail] (:bhearsum)]

Attachment: inline documentation

This covers the points mentioned and also replaces the placeholder text for other fields with permanent help text. Having the tabbed layout has really helped here - there's enough room to do this in.

Comment 4

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

Comment on attachment 728986 [details] [diff] [review]
inline documentation

>diff --git a/kickoff/templates/includes/fennec_release.html b/kickoff/templates/includes/fennec_release.html
> <div class="submit_release">
>     {{ fennecForm.buildNumber.label()|safe }}
>     {{ fennecForm.buildNumber(placeholder='1')|safe }}
>+    <div>&nbsp;</div>

Didn't we have a situation recently where RelMan wanted to start at build 2 and that caused issues ? A comment here to prevent would be good, for whatever applications it's appropriate.

Comment 5

[[e-mail] (:bhearsum)]

(In reply to Nick Thomas [:nthomas] from comment #4)
> Comment on attachment 728986 [details] [diff] [review]
> inline documentation
> 
> >diff --git a/kickoff/templates/includes/fennec_release.html b/kickoff/templates/includes/fennec_release.html
> > <div class="submit_release">
> >     {{ fennecForm.buildNumber.label()|safe }}
> >     {{ fennecForm.buildNumber(placeholder='1')|safe }}
> >+    <div>&nbsp;</div>
> 
> Didn't we have a situation recently where RelMan wanted to start at build 2
> and that caused issues ? A comment here to prevent would be good, for
> whatever applications it's appropriate.

Where the placeholder text caused confusion?

Comment 6

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

(In reply to Ben Hearsum [:bhearsum] from comment #5)
> Where the placeholder text caused confusion?

No, I mean that our text next to the buildNumber box should remind the user that we can't skip build 1 for a new version, per:

Date: Wed, 6 Feb 2013 20:53:28 -0500
From: Rail Aliiev <[e-mail]>
To: Alex Keybl <[e-mail]>
Subject: Re: Urgent: Please build mobile-only Firefox 18.0.2 (build #2)

On 17:34, Wed, 06 Feb, Alex Keybl wrote:
>Please build a mobile-only Firefox 18.0.2 (build #2) using:
>
>	https://hg.mozilla.org/releases/mozilla-release/rev/912b9ffcbaad
>
>This is off of tip/default, but I've already reviewed the very minor changes since 18.0.2 desktop. Thanks!

FTR, we have to use 18.0.2 build#1 because automation doesn't bump Gecko 
version in build > 1. It doesn't affect the final binary.

-- 
Best regards,
Rail Aliiev

Comment 7

[[e-mail] (:bhearsum)]

Attachment: add docs for build number

Thanks for the reminder about build number!

Comment 8

[[e-mail] (:bhearsum)]

I landed this into production with the new deployment tool, Chief.