Release Management/Archive/Balrog

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