Release Management/Archive/Balrog

From MozillaWiki
Jump to: navigation, search

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