PS UIFe, FFe and SRU discussions

Registered by Didier Roche

We are going to get better communication with the various key holder of the distro process for handling UIF, FF. Minor UI changes are getting a lighter process and they can even make it in a SRU.

Blueprint information

Not started
Sebastien Bacher
Didier Roche
Didier Roche
Series goal:
Accepted for saucy
Not started
Milestone target:

Related branches



Discussing FFe, UIFe, MRe, impact for the release team, sru team, doc team

State of last cycle:
 - lot of FFe, UIFe, how to get better?
 - for various reasons, a business decision was made to land features, even late, engineering and design was late
 - lack of visibility for predicting what's going to happen
   * radio silence for the first few months this cycle
   * reverting back for one point of contact instead of two?
   * design only get to test new features for first time after Final Beta milestone
   * minimum of 3 or 4 test/fix iterations required to go from first test by design to release quality
 - how to deal with things that are not disclosed in advance for business reasons?
   * we can have someone from the marketing/copywriting or design team taking the screenshots for handling the documentation team pain.
   * If feature is ready to test by design team before feature freeze, will this solve this issue?
 - the release team wants explicit sabdfl ack on bugs, not implicit.
 - can we think of the LTS +1 cycle being more disruptive than the other cycles as it's shaping the landscape for the next 2 years.
 - communication with the key holders of the process in advance will help a lot enhancing the whole feedback cycle
 - UIFe is more a coordination point for things impacting the documentation and other members.
 - Using one bug for landing multiple minors UI changes and grouping on one upload with charline giving feedback on it
 - kind of UI change limit for changes in SRU? Always ask for it, and having Charline helping to get some expert feedback


2013-04-04, seb128: that didn't happen for raring but seems still valid in its current state (no need to have a new discussion/blueprint), I'm retargetting the blueprint for "s"


Work Items

Work items:
[ivanka] Discussing about having skunking on the release, documentation, translation team members for disclosing some new features in advance without revealing them publically: TODO
[charlinepoirier] Help the release team to balance risk/benefits on every UI changes to explain more about their impact: TODO
[johnlea] Go to the tech board to try to have an explicit ack on minor UI change can go to a SRU (wrapped in bigger SRU update): TODO