Open Stack

On 12/05/16 01:44 -0400, Nikhil Komawar wrote:
>Hello all,
>
>Here are a few important announcements for the members involved in the
>Glance community.
>
>
>Priorities:
>
>=======
>
>* The Glance priorities for Newton were discussed at the contributors'
>meetup at summit.
>
>* There are a few items that were carried forward from Mitaka that are
>still our priorities and there are a couple of items from the summit
>that we have made a priority for reviews.
>
>Code review priority:
>
>* Import refactor
>
>* Nova v1, v2 support
>
>* Image sharing changes

I'm sorry for bringing this up here but I believe I wasn't around when this
discussion happened at the summit. To be honest, this strikes me as weird. I did
not expect image sharing to be a priority and I would really appreciate the
reasoning behind this. I'm a bit concerned by the impact, if any, this might or
might not have on the image import work.

I'd have voted for other topics so, I'm really curious to know the answer to the
above. Also, I'm sorry for not having been there.

>* Documentation changes [1], [2]
>
>
>The required attention from Glance team on Nova v1, v2 support is
>minimal; the people who are actively involved should review the code and
>the spec.
>
>
>Everyone is encouraged to review the Import refactor work however, if
>you do not know where to start you can join the informal syncs on
>#openstack-glance Thursdays at 1330 UTC. If you do not see people
>chatting you are more than encouraged to highlight the following irc
>nicks: rosmaita, nikhil (to the very least)
>
>
>Everyone is encouraged to review the Image sharing changes that are
>currently being discussed. Although, the constructs are not going to
>hamper the standard image workflows, the experiences of sharing may be
>different after these changes. There will be subsequent changes to the
>python-glanceclient for accommodating server changes.

Noticed you mentioned here the image sharing work won't impact the new import
workflow.

>Documentation changes are something that we must accommodate in this
>cycle; thanks to the docs team the code draft was given to us.
>Documentation liaison is working hard to get it in the right shape and a
>couple more reviewers are to be assigned to review this change. We need
>volunteers for the review work.
>
>
>Process to be adopted in Newton:
>
>==========================
>
>
>Full specs:
>
>* For all newly introduced features, API Impacting changes and changes
>that could either have an impact security or larger impact on operators
>will need a full spec against the openstack/glance-specs repo.
>
>* For each spec, you need to create a corresponding blueprint in
>launchpad [3] and indicate your intention to target that spec in the
>newton milestone. You will want to be judicious on selecting the
>milestone; if we see too many proposals for a particular milestone
>glance-core team will have to selectively reject some of those or move
>to a different milestone. Please set the url of the spec on your blueprint.
>
>* Please use the template for the full spec [4] and try to complete it
>as much as possible. A spec that is missing some critical info is likely
>to not get feedback.
>
>* Only blueprints by themselves will not be reviewed. You need a spec
>associated with a blueprint to get the proposal reviewed.

The above seems to be exactly what we've done so far. Anything I'm missing?

In Mitaka, we started writing the contributors guidelines for Glance. I believe
the above should be put there. Thoughts? (I'm volunteering you :P)

http://docs.openstack.org/developer/glance/contributing/index.html

>* The reviewers section [5] is very important for us to determine if the
>team will have enough time to review your spec and code. This
>information plays important role in planning and prioritize your spec.
>Reach out to these core-reviewer nicks [6] on #openstack-glance channel
>to see who is interested in assigning themselves to your spec.


Interestingly enough, I was going to propose to get rid of that section. I don't
think it's useful and often enough the reviewers listed in the spec are not the
ones actually reviewing the patches. I'm happy to discuss this on gerrit over a
patch. Oh, look:

https://review.openstack.org/#/c/316276/


>* Please make sure that each spec has the problem statement well
>defined. The problem statement isn't a one liner that indicates -- it
>would be nice to have this change, admins should do operations that user
>can't, Glance should do so and so, etc. Problem statement should
>elaborate your use case and explain what in Glance or OpenStack can be
>improved, what exists currently, if any, why would it be beneficial to
>make this change, how would the view of cloud change after this change, etc.
>
>* All full specs require +W from PTL/liaison
>
>
>Lite specs:
>
>* All proposals that are expected to change the behavior of the system
>significantly are required to have a lite-spec.
>
>* For a lite-spec you do not need a blueprint filed and you don't need
>to target it to particular milestones. Glance would accept most
>lite-specs until newton-3 unless a cross-project or another conflicting
>change is a blocker.
>
>* Please make sure that each lite-spec has a well defined problem
>statement. The problem statement is NOT a one liner that indicates -- it
>would be nice to have this change, admins should do operations such
>operations that user can't, Glance should do so and so, etc. Problem
>statement should elaborate your use case and explain what in Glance or
>OpenStack can be improved, what exists currently, if any, why would it
>be beneficial to make this change, how would the view of cloud change
>after this change, etc.
>
>* All lite specs should have at least two +2 (agreement from at least
>two core reviewers). There is no need to wait on +W from the PTL but it
>is highly encouraged to consult a liaison (module expert).
>
>* Lite specs can be merged irrespective of the spec freeze dates.
>

These lite specs are expected to be filled in the `lite-spec` file in
glance-specs, right?

Just want to make sure the process hasn't been changed here since Erno's patch
is still on review:

https://review.openstack.org/#/c/282517/


>Important dates to remember:
>
>=======================
>
>* June 2, R-18: newton-1
>
>* June 17, R-16: Spec soft freeze, Glance mid-cycle (15th-17th)
>(depending on attendance). If you've already booked travel contact me ASAP.

Not big deal but after looking at this list it seems the mid cycle might happen
a bit too early in the cycle. Thoughts? Is that on purpose? I'm good either way,
I just want to make sure we consider this.

>* July 14, R-12: newton-2
>
>* Jul 29, R-10: Spec hard freeze
>
>* Aug 23, R-6: final glance_store release
>
>* Aug 30, R-5: newton-3, lite-spec freeze, feature freeze, final
>glanceclient release, soft string freeze
>
>* Sept 13, R-3: RC1, hard string freeze
>
>* Oct 7, R+0: Newton release
>
>
>Spec owners and reviewers:
>
>======================
>
>* Currently there are 12 Glance core reviewers with some on hiatus, some
>part time core reviewers (even less than 50%) and a few others with more
>than 70% upstream time.
>
>* I have consolidated some information that we effectively have a little
>more than 5 core reviewers with 100% upstream time. I hope to improve
>that over the next couple of months if enough people are interested in
>contributing upstream who have already expressed in reviewing more
>Glance code.

I did a similar analysis in my summary email from Mitaka. Does the above
considers Stuart hiatus?

http://lists.openstack.org/pipermail/openstack-dev/2016-March/088811.html

Flavio

>
>* So, while we would ideally be able to knock out 6 full specs in a
>cycle (with each spec requiring at least two cores associated with it),
>with current effectiveness we would like to target 2-3 specs depending
>on the size of the changes.
>
>* All spec owners are highly encouraged to start a conversation with one
>or two of the core-reviewers mentioned in [6] and see the possibility of
>having 'champions' on those specs.
>
>* While the associated core reviewers are not required to review the
>entire set of patches associated with that spec, they do however are a
>point of contact, for representing Glance's point of view on the spec.
>
>* If you are looking to associate yourself as a reviewer to a spec and
>do not know which one you should pick, feel free to reach out to me.
>
>* Also, if you are looking to make your mark and trying to work your way
>into the core team, it will be highly appreciated if you assign yourself
>to an important spec and help them drive the feature.
>
>
>[1] http://lists.openstack.org/pipermail/openstack-docs/2016-May/008536.html
>
>[2] https://review.openstack.org/#/c/312259
>
>[3] https://blueprints.launchpad.net/glance
>
>[4] https://github.com/openstack/glance-specs/blob/master/specs/template.rst
>
>[5]
>https://github.com/openstack/glance-specs/blob/master/specs/template.rst#reviewers
>
>[6] core-reviewer nicks: rosmaita, jokke_, flwang, flaper87, hemanthm,
>sigmavirus24, kairat, kragniz, mfedosin, nikhil, sabari, mclaren
>
>[7] https://review.openstack.org/315347
>
>-- 
>
>Thanks,
>Nikhil
>
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-- 
@flaper87
Flavio Percoco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160513/d3bc6bec/attachment.pgp>