[openstack-dev] OpenStack Developer Mailing List Digest March 19-25
mike at openstack.org
Sat Mar 26 03:09:22 UTC 2016
HTML version: http://www.openstack.org/blog/2016/03/openstack-developer-mailing-list-digest-20160318-2/
* redrobot: The Barbican API guides is now being published. 
* jroll: ironic 5.1.0 released as the basis for stable/mitaka.
* ttx: All RC1s up for milestones-driven projects.
* zara: storyboard.openstack.org sends emails now!
* noggin143: my first bays running on CERN production cloud with Magnum.
* sdague: Grenade upgraded to testing stable/liberty -> stable/mitaka and
stable/mitaka -> master.
* Tell us yours via IRC with a message “#success [insert success]”.
* All: https://wiki.openstack.org/wiki/Successes
PTL Election Conclusion and Results
* Results are in, congrats to everyone! 
* Appointed PTLs by the TC for leaderless Projects :
- EC-API: Alex Andrelevine
- Stable Branch Maintenance: Tony Breeds
- Winstackers: Claudiu Belu
Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/090422.html
Candidate Proposals for Technical Committee Positions Are Now Open
* Important dates:
- Nominations open: 2016-03-25 00:00 UTC
- Nominations close: 2016-03-31 23:59 UTC
- Election open: 2015-04-01 00:00 UTC
- Election close: 2015-04-07 23:59 UTC
* More details on the election 
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/090421.html
Release countdown for week R-1, Mar 27 - Apr 1
- Project teams following the cycle-with-milestone model should be testing
their release Candidates.
- Project teams following the cycle-with-intermediary model should have at
least one Mitaka release and determine if another release is needed before
the end of the Mitaka cycle.
- All projects should be working on release-critical-bugs.
* General Notes:
- Global-requirements list is still frozen.
- If you need to change a dependency for release-critical-bug fix, provide
enough details in the change request.
- Master branches for all projects following cycle-with-milestone are open
for Newton development work.
* Release Actions:
- Projects following cycle-with-intermediary without clear indication of
cutting their final release:
- These projects should contact the release team or submit a release request
to the releases repository as soon as possible. Please submit a request by
Wednesday or Thursday at the latest.
+ After March 31st, feature releases will be counted as part of Newton
- The release team will have reduced availability between R1 and summit due
to travel. Use the dev mailing list to contact the team and include
"[release]" in the subject.
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/089701.html
Bots and Their Effects: Gerrit, IRC, other
* Bots are very handy for doing repetitive tasks.
* These require require permissions to execute certain actions, require
maintenance to ensure they operate as expected and do create output which is
music to some and noise to others
* From an infra meeting , this is what has been raised so far:
- Permissions: having a bot on gerrit with +2 +A is something we would
like to avoid
- "unsanctioned" bots (bots not in infra config files) in channels
shared by multiple teams (meeting channels, the -dev channel)
- Forming a dependence on bots and expecting infra to maintain them ex
post facto (example: bot soren maintained until soren didn't)
- Causing irritation for others due to the presence of an echoing bot
which eventually infra will be asked or expected to mediate
- Duplication of features, both meetbot and purplebot log channels and host
the archives in different locations
- Canonical bot doesn't get maintained
* It's possible bots that infra currently maintains have features that folks
are unaware of.
* Bots that +2 reviews and approve them can be a problem when taking into
account of schedules, outages, gate issues, etc.
* The Success bot for example is and added feature that takes advantage of the
already existing status bot.
* What are the reasons that people end up writing their own bots instead of
contributing to the existing infrastructure bots when applicable?
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#90262
Semantic Version On Master Branches After RC
* The release team assumes three options someone would choose when installing
- Tagged versions from any branch.
+ Clear, and always produces deployments that are reproduceable, with
versions distinct and increasing over time.
- Untagged versions on a stable branch.
- Untagged versions on the master branch
+ Options 2 and 3 are something around release cycle boundaries.
+ Produce the same version numbers in different branches for a short period
+ The release team felt it was extremely unlikely that anyone would mix
option 2 and 3, because that will make upgrades difficult.
* Some distributions want to package things that are not tagged as releasable
+ They are in their development cycles and want/need to keep up with trunk
throughout the whole cycle.
+ A lot of changes are introduced in a cycle with new features,
deprecations, removals, non-backwards compatibility etc. Wit these
continually provided up-to-date packages, they are able to test them
- It's a lot of work to package things, and distributions want to do it
+ If distributions started packaging OpenStack only when the official
stable release would be out, it would take us several weeks/months to get
a stable package out.
+ Projects that use packages to deploy are then delayed for their own
release to test these packages their consuming. (e.g. TripleO, Packstack,
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#90149
Our Install Guides Only Cover Defcore - What About Big Tent?
* Until recently, projects like Manila  and Magnum have been accepted in the
install guides, but we're having issues initially because they aren't
considered by the defcore working group.
- With expansion of projects coming from big tent, the documentation team has
projects requesting their install documentation to be accepted. The
documentation team today maintain and verifies the install documentation
for each release can be a lot of work with the already accepted OpenStack
- Make install guides easy to contribute for projects in the big tent.
- Not end up having the documentation team maintain all projects install
- As an operator, I should be able to easily discover install documentation
for projects in the big tent.
- With accessible install documentation projects can hopefully have:
+ Improved adoption
+ More stable work from bug reports with people actually able to install
and test the project.
* Proposal: Install documentation can live in a project's repository so they
can maintain and update.
- Have all these documentation sources rendered to one location for easy
* Full thread: http://lists.openstack.org/pipermail/openstack-dev/2016-March/thread.html#90214
 - http://developer.openstack.org/api-guide/key-manager/
 - http://lists.openstack.org/pipermail/openstack-dev/2016-March/090422.html
 - http://eavesdrop.openstack.org/meetings/tc/2016/tc.2016-03-22-20.01.html
 - https://wiki.openstack.org/wiki/TC_Elections_April_2016
 - http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-03-22-19.02.log.html
 - https://review.openstack.org/#/c/213756/
More information about the OpenStack-dev