[Openstack-operators] OpenStack Developer Mailing List Digest Feb 20-26
mike at openstack.org
Sat Feb 27 01:18:24 UTC 2016
HTML rendered version: http://www.openstack.org/blog/2016/02/openstack-developer-mailing-list-digest-20160226/
Audience for Release Notes
* We have 3 potential audiences for release notes:
- Developers consuming libraries or other code directly.
- Deployers and operators.
* Two kinds of documentation being discussed:
- Reno  for release notes 
+ Keep in mind the audience is *not* someone who is necessarily going to be
looking at code or writing apps based on libraries we produce.
+ Highlight information that deployers and operators will need, like
changes to configuration options or service behaviors.
+ Describe REST API changes that an end-user may need to know about.
- In-tree developer documentation  for Developers.
+ Internal details, library API changes, etc. -- any changes the deployer
is not going to see.
* The two sets of documentation are meant for different purposes, so we need to
think about what information we publish in each.
A Proposal to Separate the Design Summit
- Since the beginning, we've had face to face time at Design Summits to
discuss development cycles to set goals and organize the work for the
upcoming 6 months.
- A more traditional conference took place at the same time to ensure
interaction between upstream and downstream parts of our community.
* Current issues
- For developers:
+ Difficult to focus on upstream work with so many distractions coming
from the conference.
+ As a result the summit is less productive, and we form midcycles to fill
- For companies:
+ Flying all their developers to expensive cities and conference hotels for
the summit is pretty costly. - The goals of the summit location reaching
out to users everywhere does not necessarily align with the goals of the
design summit location.
+ Not enough time to build products on top of the recent release.
- Not enough time for users to try out the new release to have feedback.
- Finding venues that can accommodate both events is becoming increasingly
* Proposal: Split up the events
- The first event would be for upstream technical contributors of OpenStack.
+ Held in a simpler, scaled-back setting that would let all OpenStack
project teams meet in separate rooms, but in a co-located event that
would make it easy to have ad-hoc cross-project discussions.
+ It would be held in closer to the centers of mass of contributors, in
+ It would happen a couple of weeks /before/ the previous cycle release.
There is a lot of overlap between cycles. Work on a cycle starts at the
previous cycle feature freeze, while there is still 5 weeks to go. Most
people switch full-time to the next cycle by RC1. Organizing the event
just after that time lets us organize the work and kickstart the new
cycle at the best moment. It also allows us to use our time together to
quickly address last-minute release-critical issues if such issues
- The second event would be the main downstream business conference.
+ This includes high-end keynotes, marketplace, and break out sessions.
+ Organized two or three months /after/ the release, to give time
downstream users to deploy and build products on top of the release.
+ This will better allow us to gather feedback on the recent release,
a gather requirements for the next cycle.
+ A subset of contributors who would like to participate in sessions can
collect and relay feedback to other team members (similar to the
operators midcycle meetups).
* The split should reduce the number of midcycle events, however, if they're
still needed, they could happen at the conference event (which is in the
middle of the cycle).
* The split means that we need to stagger the events and cycles. We have
a long time between Barcelona and the Q1 Summit in the US, so the idea would
be to use that long period to insert a smaller cycle (Ocata) with a release
early March, 2017 and have the first specific contributors event at the start
of the P cycle, mid-February, 2017. With the already-planned events in 2016
and 2017 it is the earliest we can make the transition. We'd have a last,
scaled-down design summit in Barcelona to plan the shorter cycle.
* Operators midcycle will still continue to happen.
* Voiced Concerns and Answers:
- This creates two events instead of one.
- Creates community split, with developers skipping the main and
non-developers not providing any feedback to the contributor specific
+ There will still be a lot of strategic discussions at the main event.
+ This is where we look at the N-1 release and start drawing plans and
cross-project themes for the N+1 release.
+ We don't need every developer there, but we still need a significant
chunk of them, with every team represented, so that we can have those
strategic and cross-project discussions.
+ Someone who wants to keep touch with development could still make only
one trip, so it's not expected for the communities to be split. We'd
still all be represented in the main event.
- Losing the main summit as an excuse to fund developers' travel. Some
developers are only sent to the Design summit because the main event is
happening at the same time.
+ If you have to pretend to attend the Summit to be able to attend the
Design Summit instead, there is deception involved. You should a talk
with your employer on where the most value lies for you in attending
+ The Foundation also has the Travel support program to cover the gaps .
- The fear of US-centricity (translating from "closer to the centers of mass
of contributors"). This makes travel cost cheaper at the expense of making
it more costly for non-US parts of our community.
+ The goal is "minimize and *balance* travel costs for existing
contributors". There will still be some continent rotation involved, but
we need to balance cost and fair.
- The lost of midcycle spirit. Some people really like the midcycles as they
stand: separated small events where only your small team is around. The
split appears to reduce the likelihood, the need, or the funding for such
+ While the hope is the proposed format will let us fulfill all our team
socialization needs, it's true that there will be other people around,
and it will feel a lot less exclusive and special.
+ The trade-off is that having people all together encourages cross-project
work and breaks silos.
 - http://docs.openstack.org/developer/reno/
 - http://releases.openstack.org/
 - http://developer.openstack.org/
 - https://www.openstack.org/summit/austin-2016/austin-and-travel/#travel-support
More information about the OpenStack-operators