... for throttling user initiated requests. See also bug 733274 for renaming existing throttling.
mass component change
mass priority change after component move
This came up in the postmortem today - lmandel was in favor of having this functionality so that we could do all the prep for a release on the day before, then leave both foreground & background updates disabled until the instant we want to ship. Co-ordinating shipping with marketing/website/other changes is becoming an issue, so anything we can do to preload testing is useful. QA would need some way to get around the throttling to test (I jokingly suggested &reallyreallyforce=1 but there must be better ways). lmandel was OK with not offering updates for the hours or so between testing and shipping, since updating twice in close succession is not great UX.
Nick, RelMan - do you think this is still desired? It would be a good contributor bug, if so.
I'm not sure how I got a needinfo for lsblakk in there, whoops....
I'll leave it to Releases Management to say.
To rephrase, this bug is about the fact that a user can force the update after the push to release-cdntest (usually done the day before the release) and before we enable updates, right? I think we should indeed have this bug implemented.
(In reply to Sylvestre Ledru [:sylvestre] from comment #7) > To rephrase, this bug is about the fact that a user can force the update > after the push to release-cdntest (usually done the day before the release) > and before we enable updates, right? > > I think we should indeed have this bug implemented. Not quite. That has nothing to do with Balrog (users either pave over with a new installer, or change their channel to -cdntest). This bug would give us control over the rate at which updates are served when ?force=1 is set (
What would be the use case for that? Sorry, this is pretty unclear for me now.
This sounds like a nice idea to me and might give us more flexibility. I can't remember the original discussion. Can we talk about it after we ship 49? :D
(In reply to Sylvestre Ledru [:sylvestre] from comment #9) > What would be the use case for that? Sorry, this is pretty unclear for me > now. See comment #10 - Liz said it well :). It's hard to imagine a concrete use case in advance, but we've really tried to design Balrog to handle future things we haven't yet found a use for.