Release Management/Archive/Balrog
From MozillaWiki
Notes
From meeting with RelEng on May 24th, 2012
- P1: Throttling updates for a specific platform, OS version, service pack, locales etc.
- might have to add wildcard matching
- What can we *not* key off of? (let's test more, but seemingly we should be able to key off any combo)
- P1: Ability to offer updates based upon future new keys without making significant changes to balrog
- Not trivial, new column in table - adjust queries
- Would have to be a planned-in-advance feature request
- P1: I'd like to be able to do things like the m-c -> maple -> m-c merge in the future without significant pain
- We should be able to point a channel to some other channel, then move back
- client-side change to what channel they ping? channel is explicilty excluded from the update mar -- unless we did a custom mar that alters that
- P1: Ability to go through data about updates requested/served (logging) bug 758373
- add logging for if a request was throttled or not
- P2: Being able to request updates to a specific buildid (in support of Firefox Rewind, a dream feature we have that will allow "updates" to previously used buildids for our testing audience). I heard this may break the currenty model of Balrog - we should talk about that soon. We don't have a feature page for Firefox Rewind yet.
- This can likely be done client-side, using direct bouncer links for previous updates' mars
- tracking which updates offered to a user's profile (any chance they get the wrong platform?)
- P3: Ability to stop offering an update after X people hit it
- P3: Ability to stop offering an update after a certain date/time
- P∞: throttling curve based on date/time/X people hit