The content below is taken from the original (OpenStack Developer Mailing List Digest November 21-27), to continue reading please visit the site. Remember to respect the Author & Copyright.

Success Bot Says

• vkmc: We got 7 new interns for the Outreachy program December-March 2015 round.
• bauzas: Reno in place for Nova release notes.
• AJaeger: We now have Japanese Install Guides published for Liberty [1].
• robcresswell: Horizon had a bug day! We made good progress on categorizing new bugs and removing old ones, with many members of the community stepping up to help.
• AJaeger: The OpenStack Architecture Design Guide has been converted to RST [2].
• AJaeger: The Virtual Machine Image guide has been converted to RST [3].
• Ajaeger: Japanese Networking Guide is published as draft [4].
• Tell us yours via IRC with a message “#success [insert success]”.

Release countdown for week R-18, Nov 30 – Dec 4

• All projects following the cycle-with-milestones release model should be preparing for the milestone tag.
• Release Actions:
  • All deliverables must have Reno configured before adding a Mitaka-1 milestone tag.
  • Use openstack/releases repository to manage the Mitaka-1 milestone tags.
  • One time change, we will be simplifying how we specify the versions for projects by moving to only using tags instead of the version entry for setup.cfg.
• Stable release actions: Review stable/liberty branches for patches that have landed since the last release and determine if your deliverables need new tags.
• Important dates:
  • Deadline for requesting a Mitaka-1 milestone tag: December 3rd
  • Mitaka-2: Jan 19-21
  • Mitaka release schedule [5]

Common OpenStack ‘Third-Party’ CI Solution – DONE!

• Ramy Asselin who has been spearheading the work for a common third-party CI solution announces things being done!
  • This solution uses the same tools and scripts as the upstream Jenkins CI solution.
  • The documentation for setting up a 3rd party ci system on 2 VMs (1 private that runs the CI jobs, and 1 public that hosts the log files) is now available here [6] or [7].
  • There a number of companies today using this solution for their third party CI needs.

Process Change For Closing Bugs When Patches Merge

• Today when a patch merges with ‘Closes-Bug’ in the commit message, that marks the associated bug as ‘Fix Committed’ to indicated fixed, but not in the release yet.
• The release team uses automated tools to mark bugs from ‘Fix Committed’ to ‘Fix Released’, but they’re not reliable due to Launchpad issues.
• Proposal for automated tools to improve reliability: Patches with ‘Closes-Bug’ in the commit message to have the bug status mark the associated bug as ‘Fix Released’ instead of ‘Fix Committed’.
• Doug would like to have this be in effect next week.

Move From Active Distrusting Model to Trusting Model

• Morgan Fainberg writes most projects have a distrusting policy that prevents the following scenario:
  • Employee from Company A writes code
  • Other Employee from Company A reviews code
  • Third Employee from Company A reviews and approves code.
• Proposal for a trusting model:
  • Code reviews still need 2x Core Reviewers (no change)
  • Code can be developed by a member of the same company as both core reviewers (and approvers).
  • If the trust that is being given via this new policy is violated, the code can [if needed], be reverted (we are using git here) and the actors in question can lose core status (PTL discretion) and the policy can be changed back to the “distrustful” model described above.
• Dolph Mathews provides scenarios where the “distrusting” model either did or would have helped:
  • Employee is reprimanded by management for not positively reviewing & approving a coworkers patch.
  • A team of employees is pressured to land a feature with as fast as possible. Minimal community involvement means a faster path to “merged,” right?
  • A large group of reviewers from the author’s organization repeatedly throwing *many* careless +1s at a single patch. (These happened to not be cores, but it’s a related organizational behavior taken to an extreme.)

Stable Team PTL Nominations Are Open

• As discussed [8][9] of setting up a standalone stable maintenance team, we’ll be organizing PTL elections over the coming weeks.
• Stable team’s mission:
  • Define and enforce the common stable branch policy
  • Educate and accompany projects as they use stable branches
  • Keep CI working on stable branches
  • Mentoring/growing the stable maintenance team
  • Create and improve stable tooling/automation
• Anyone who successfully contributed to a stable branch back port over the last year can vote in the stable PTL election.
• If interested, reply to thread with your self-nomination.
• Deadline is 23:59 UTC Monday, November 30.
• Election will be the week after.
• Current candidates:
  • Matt Riedmann [10]
  • Erno Kuvaja [11]

Using Reno For Libraries

• Libraries have two audiences for release notes:
  • Developers consuming the library.
  • Deployers pushing out new versions of the libraries.
• To separate the notes from the two audiences and avoid doing manually something that we have been doing automatically, we can use Reno for just deployer release notes.
• Library repositories that need Reno should have it configured like service projects, with separate jobs and a publishing location different from their developer documentation [12]

Releases VS Development Cycle

• Thierry writes that as more projects enter the Big Tent, there have recently been questions about release models and development cycle.
• Some projects want to be independent of the common release cycle and dates, but still keep some adherence to the development cycle. Examples:
  • Gnocchi wants to be completely independent of the common development cycle, but still maintain stable branches.
  • Fuel traditionally makes their releases a few months behind the OpenStack release to integration all the functionality there.
• All projects above should current be release:independent, until they are able to (and willing) to coordinate their own releases with the projects following the common release cycle.
• The release team currently supports 3 models:
  • release:cycle-with-milestones is the traditional Nova model with one release at the end of a 6-month dev cycle and a stable branch derived from that.
  • release:cycle-with-intermediary is the traditional Swift model, with releases as-needed during the 6-month development cycle, and a stable branch created from the last release in the cycle.
  • release:independent, for projects that don’t follow the release cycle at all.
    • Can make a release supporting the Mitaka release (including stable updates).
      • Can call the branch stable/mitaka even after the Mitaka release cycle, as long as the branch is stable and not development.
    • Should clearly document that their release is *compatible with* the OpenStack Mitaka release, rather than *part of* the Mitaka release.