Open Stack

Perma link: http://www.openstack.org/blog/2015/11/openstack-developer-mailing-list-digest-november-20151121/

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]

* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080527.html

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.
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080058.html

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.
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/078280.html

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.)
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080238.html

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]

* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080249.html

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]
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080694.html


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.
- Full thread: http://lists.openstack.org/pipermail/openstack-dev/2015-November/080233.html


[1] - http://docs.openstack.org/ja/
[2] - http://docs.openstack.org/arch-design/
[3] - http://docs.openstack.org/image-guide/
[4] - http://docs.openstack.org/draft/ja/networking-guide/
[5] - https://wiki.openstack.org/wiki/Mitaka_Release_Schedule
[6] - https://github.com/openstack-infra/puppet-openstackci/tree/master/contrib
[7] - https://git.openstack.org/cgit/openstack-infra/puppet-openstackci/tree/contrib/README.md
[8] - http://www.openstack.org/blog/2015/11/openstack-developer-mailing-list-digest-november-20151107/#stable-team
[9] - http://www.openstack.org/blog/2015/11/openstack-developer-mailing-list-digest-november-20151114/#stable-team
[10] - http://lists.openstack.org/pipermail/openstack-dev/2015-November/080262.html
[11] - http://lists.openstack.org/pipermail/openstack-dev/2015-November/080607.html
[12] - http://docs.openstack.org/developer/reno/