The content below is taken from the original (OpenStack Developer Mailing List Digest October 29 to November 4), to continue reading please visit the site. Remember to respect the Author & Copyright.

Cross Project Proprietary Driver Code Recap

• At the Barcelona design summit there was a cross-project session on the challenge we’re running where to draw the line with proprietary driver code [1].
• Option 1:
  • All libraries imported by the driver must be licensed such that they are redistributable by package maintainers and must be compatible with the Apache license [2].
  • Existing non-compliant driver code would need to be updated by Queens release.
  • Code that’s not imported at the driver runtime (CLIs, external binaries, remote application servers) are acceptable to not be redistributable.
• Option 2:
  • Remove all drivers that are not completely open source and contained in the project repositories.
• Option 3:
  • Require majority of the business logic is in the open source code.
  • Allow third party, non-redistributable libraries and CLIs that are used as more of an “RPC” type interface.
  • Reviewers should be able to review the driver and at least get some idea of the steps the driver is doing to perform requests.
• Jeremy Stanley would like to take option 1 a step further and provide better guidance. We should recommend against drivers calling proprietary tools. Some vendors go this route because they already have a non-free CLI tool and avoid code cost duplication. Other vendors may do this to copy other vendors.
  • The desire of having things redistributable is so that downstream consumers of OpenStack are not beholden to vendors just to be able to use our (free!) software with hardware they have.
  • For example
    • Vendor decides to stop supporting a proprietary command line tool
    • You decide to stop paying support contracts to download that tool
    • Vendor disappears
• Full thread

Ocata Release Management Communication

• To the PTL’s or or volunteers filling in for a PTL:
• Email
  • The “[release]” topic tag on the openstack-dev mailing list will be used for important messages.
  • Countdown email with updates on focus, tasks, and upcoming dates.
• IRC
  • Be available on #openstack-release, especially during deadline periods. It’s up to you to configure an IRC bouncer to ensure this.
• Written documentation
  • Read the Ocata cycle schedule [3].
  • Some projects have their own deadlines. Feel free to submit a patch to this schedule within the openstack/release repository.
• The Ocata cycle overlaps with several major holidays. If you’re planning time off, please make sure your duties are covered by someone else on your team. Let the release team know about this so they’re not waiting for your +1.
• Failing to follow through on a needed process step may block you from successfully meeting deadlines or releasing.
• Releases milestones and deadlines are date-based, not feature based. When the date passes, so does the milestone. If you miss it, you miss it.
• Full thread

Release Announcements

• The release team at the Barcelona summit discussed how to improve release announcements as posting them to openstack-dev and openstack-announce has proven to be pretty noisy.
• Proposed solution is to move these announcements to another mailing list. Choices are:
  • release-announce
  • release-announcements
• Full thread

POST /api-wg/news

• API guidelines that will be merged in one week if there is no further feedback:
  • Complex queries [4]
  • Specify time intervals based filtering queries [5]
  • Clarify why CRUD is not a great descriptor [6]
• Guidelines under review:
  • Define pagination guidelines [7]
  • Add API capabilities discovery [8]
• Full thread

Release Countdown for Week R-15

• Focus:
  • Teams should be focusing on wrapping up incomplete work left over from the end of the Newton cycle.
  • Finalizing and announcing plans from the summit
  • Completing specs and blueprints
• General notes:
  • Stable and independent releases have resumed.
  • We cut time out of the Ocala schedule before the first milestone. Ocata-1 will be during R-14.
• Release actions:
  • Release liaisons should add their name and contact information to the wiki [9].
  • Release liaisons should configure their IRC clients to join #openstack-release.
  • Release liaisons should review the release models for all deliverables and make any updates with patches to openstack/governance before the first milestone.
  • PTLs should add their acknowledgement of the Ocala series community goal [10]
• Important dates:
  • Ocata 1 Milestone: 17 Nov
  • Ocata release schedule [11]
• Full thread