Closed Bug 1770837 Opened 3 years ago Closed 3 years ago

Port bug 1607266 - Automatically set update rates for beta releases

Categories

(Thunderbird :: Build Config, task)

Tracking

(Not tracked)

RESOLVED FIXED
102 Branch

People

(Reporter: rjl, Assigned: rjl)

Details

Attachments

(2 files)

Should be able to set the background/update rate for beta releases automatically and save a few clicks.

We generally use lower values for the background/update rate on early betas and
increase as we iterate. It's rare that we do more than 4 betas in a cycle. In
those cases, the default "null" value will not change the rate.

Assignee: nobody → rob
Status: NEW → ASSIGNED
Target Milestone: --- → 102 Branch

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/66fc564e5788
Port bug 1607266: Automatically set AUS update rate for betas. r=thunderbird-reviewers,darktrojan

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED

I'd like to have some input on this change ;)

(In reply to Rob Lemley [:rjl] from comment #1)

Created attachment 9277836 [details]
Bug 1770837 - Port bug 1607266: Automatically set AUS update rate for betas. r=#thunderbird-reviewers

We generally use lower values for the background/update rate on early betas and increase as we iterate.

Generally true. But the rat that is set is also moderated by the day of week that we release, the patches that were taken, how quickly we need user feedback, and other factors. That said, if this is to be automated we must pick a rate that is going to be good for the average case.

It's rare that we do more than 4 betas in a cycle.

Actually it is not rare. The first half of the 91 esr cycle was more frequent than four. 92, 93, 94, 95 had five, and 91 had six. It didn't drop to four until 96. The cadence we worked with had been:
week 1: b1 on ~Tuesday
week 2: b2, b3 on Monday and Thursday
week 3, b4, b5 on Monday and Thursday
week 4, b6 on Monday

I think we should anticipate something similar for v102, unless we have a conversation that leads to a different conclusion.

those cases, the default "null" value will not change the rate.

But by the time we do the next beta, the rate it is often at 100, which is too high for a starting rate. No?
I think the default should be in the 35-50 range.

I'd like to suggest the following:
week 1: b1 rate 15
week 2: b2, b3 rate 25
week 3, b4, b5 rate 35
week 4, b6 rate 35

If we remove the "week" labels above, I think those rates would also be reasonable for the slower cadence of one beta per week.

Can we at the same time create a timed rate increase?

Flags: needinfo?(rob)

Oops, yes I wanted your input before landing.

Tese are defaults and can always be changed manually as we do now. But, we should aim to get them as close to what we want as possible as this is a first step to "automatic" betas.

The problem with factors based on day or time is that the calculation is done when the code is pushed, not when we press the "ship" button in Ship-it.

I'll make the adjustments you suggested and land to see how well it works for us.

To be clear, changing to:

beta:
    by-beta-number:
        '1': 15
        '(2|3)': 25
        '(4|5|6)': 35
        default: null
Status: RESOLVED → REOPENED
Flags: needinfo?(rob)
Resolution: FIXED → ---

Pushed by thunderbird@calypsoblue.org:
https://hg.mozilla.org/comm-central/rev/0de46bc2bf59
Set beta update rates based on relman feedback. r=wsmwk

Status: REOPENED → RESOLVED
Closed: 3 years ago3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: