[Openstack-operators] OpenStack Developer Mailing List Digest January 16-22

Mike Perez mike at openstack.org
Sat Jan 23 01:29:15 UTC 2016

Perma link: http://www.openstack.org/blog/2016/01/openstack-developer-mailing-list-digest-20160122

Success Bot Says
- mriedem: nova liberty 12.0.1 released [1].
- OpenStack Ansible Kilo 11.2.7 has been released.
- OpenStack-Ansible Liberty 12.0.4 has been released.
- Tell us yours via IRC with a message “#success [insert success]”.
- All: https://wiki.openstack.org/wiki/Successes

- License requirement clarification for big tent projects [2].
- Make constraints opt in at the test level [3].
- OSprofiler is now an official OpenStack project [4].

* TC approved:
    - Deprecate individual CLIs in favor of OpenStack client [5].
    - clouds.yaml support in clients [6].
* Current open specs: https://review.openstack.org/#/q/status:open+project:openstack/openstack-specs

Release Count Down For Week R-10, Jan 25-29
* Focus: with the second milestone behind us, project teams should be focusing
  on wrapping up new feature work and stabilizing recent additions.
* Release actions:
  - Strictly enforcing library release freeze before M3 (5 weeks).
  - Review client/integration libraries and whatever other libraries managed by
    your team.
  - Ensure global requirements and constraints lists are up to date with
    accurate minimum versions and exclusions.
  - Quite a few projects with unreleased changes on stable/liberty branch.
    Check for your project [7].
* Important dates:
  - Final release for non client libraries: February 24th
  - Final release for client libraries: March 2nd
  - Mitaka-3: Feb 29 through March 4 (includes feature freeze and soft string freeze).
  - Mitaka release schedule [8].
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-January/084678.html

Stabilization Cycles: Elaborating on the Idea To Move It Forward
* At the Tokyo summit, the OpenStack Development Theme session, in which people
  discuss overall focus in shared effort, having cycles to stabilize projects
  was brought.
* A project could decide to spend some percentage of time of the cycle on
  focusing on bug fixing, review backlog, refactoring, instead of entirely on
  new features.
* Projects are already empowered to do this, however, maybe the TC could work
  on formalizing this process so that teams have a reference when they want to.
* Some contributors from the summit feel they need the Technical Committee to
  take leadership on this, so that they can sell it back to their companies.
* Another side of discussion, healthy projects should naturally come up with
  bursts of feature addition and burst of repaying technical debt continuously.
  - Imposing specific periods of stabilization prevents reaching that ideal
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-January/084564.html

[1] - http://lists.openstack.org/pipermail/openstack-announce/2016-January/000922.html
[2] - http://governance.openstack.org/reference/licensing.html
[3] - https://review.openstack.org/#/c/267149/1
[4] - https://review.openstack.org/#/c/266632/
[5] - http://specs.openstack.org/openstack/openstack-specs/specs/deprecate-cli.html
[6] - http://specs.openstack.org/openstack/openstack-specs/specs/clouds-yaml-support.html
[7] - http://paste.openstack.org/show/484431/
[8] - http://docs.openstack.org/releases/schedules/mitaka.html

More information about the OpenStack-operators mailing list