Port bug 1607266 - Automatically set update rates for beta releases
Categories
(Thunderbird :: Build Config, task)
Tracking
(Not tracked)
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.
Assignee | ||
Comment 1•3 years ago
|
||
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.
Updated•3 years ago
|
Updated•3 years ago
|
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
Comment 3•3 years ago
|
||
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-reviewersWe 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?
Assignee | ||
Comment 4•3 years ago
|
||
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
Assignee | ||
Comment 5•3 years ago
|
||
Assignee | ||
Updated•3 years ago
|
Pushed by thunderbird@calypsoblue.org:
https://hg.mozilla.org/comm-central/rev/0de46bc2bf59
Set beta update rates based on relman feedback. r=wsmwk
Description
•