OpenStack Developer Mailing List Digest November 21-27

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.