Re: [openstack-dev] [glance] Newton priorities, processes, dates, spec owners and reviewers
I was hoping that this thread won't be a discussion thread because it's meant to be an announcement and I did encourage people to send me feedback last week/meeting and on the ML too so that we can come up with something that we can stick to. I wanted to send this out as early. Also, some individuals have sent me complaints for the lack of focus in the team. Anyway, I want for us to stick to most of what's in this thread and I will give my comments below. Also, I am planning to publish docs for those processes and priority items (next week as this week has been mostly discussions) I am willing to take comments/reviews on those so that we can collaborate more, but let's try to knock those out soon. Because, we all care about getting things done, right? ;-) Another individual who had concerns after reading this email reached out to me to get clarification. I plan to send more notices/docs on lite-specs/specs (process, docs -- as above), focus for each week, etc. in the upcoming weeks. On 5/13/16 4:25 PM, Flavio Percoco wrote: > 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 have answered the impact to import part below. The roadmap ppt from Mitaka was used and the Hierarchical access was something I saw. To have the right semantics for that access pattern we need to work with our existing image sharing model. You can find the reasons for it on the review ( https://review.openstack.org/#/c/271019/ ). Also, we've been discussing this since Mitaka and we did not want to do this in then. At the meetup, (those who were there) evaluated what all was proposed during the summit and then came up with a list that made sense. Glare was listed on the whiteboard and it's considered as a side priority ( http://lists.openstack.org/pipermail/openstack-dev/2016-May/093704.html ) as we have some cross project prototyping to finish too this cycle. The intent is to get a Glare API ready this cycle that can then be more concrete in Ocata is what I was communicated before the summit and that's what I have taken forward. Glance v1 deprecation doesn't need much reviews, it's a process work and the mostly outside of Glance. So, are Nova v1, v2 reviews that minimally involve glance-cores. The glance_store refactor is something that was agreed to first do the functional testing (non-defined priority) and answer the open questions ( https://etherpad.openstack.org/p/newton-glance-store-api-refactor ). Categorization/centralization was mostly agreed upon at the summit but then after coming back some people have changed their mind on centralization etc. Also, we are still working on breaking it down for helping text, then categorizing etc. So, this can be done as a non-defined priority. We can take the bits and pieces that are ready and not controversial and see them through. (No comments on ML for this please, I would like spec specific comments on the respective specs) Micro-versions and rolling upgrades was something communicated to me -- as time permits work. So, they need to be considered after mid-cycle. Quotas was too complicated for one cycle and having stuff in the library will meet the hierarchical needs. (Lib is still WIP) Import refactor is something we saw as a implementation only phase for Newton with most of the design discussion on it done on or before the summit. The merged spec for it has pretty broad scope and we think of the whole implementation when we look at it. However, we all agreed for a MVP implementation for import this cycle (thanks to Stuart for the awesome effort leading the design & initial patches of it). Brian Rosmaita and I are going to see the rest of it through. So, the more effort is required on the how, what, etc. communication that I'm working on. > > 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 >>
Re: [openstack-dev] [glance] Newton priorities, processes, dates, spec owners and reviewers
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
Re: [openstack-dev] [glance] Newton priorities, processes, dates, spec owners and reviewers
On 5/12/16 1:51 PM, Doug Hellmann wrote: > Excerpts from Nikhil Komawar's message of 2016-05-12 01:44:06 -0400: >> 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 > Is "Import refactor" what you're calling the work on the new API to get > images into glance to solve the DefCore compatibility issue? > > Doug Yes, we call it that as per the (original) spec review title. > >> * Nova v1, v2 support >> >> * Image sharing changes >> >> * 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. >> >> >> 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 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. >> >> * 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
Re: [openstack-dev] [glance] Newton priorities, processes, dates, spec owners and reviewers
Excerpts from Nikhil Komawar's message of 2016-05-12 01:44:06 -0400: > 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 Is "Import refactor" what you're calling the work on the new API to get images into glance to solve the DefCore compatibility issue? Doug > > * Nova v1, v2 support > > * Image sharing changes > > * 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. > > > 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 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. > > * 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
[openstack-dev] [glance] Newton priorities, processes, dates, spec owners and reviewers
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 * 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. 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 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. * 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. 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. * 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:
