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/
_______________________________________________
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
