Re: [openstack-dev] [Glance] Core nominations.
Thank you all! The nominations and the consolidation has been implemented. Cheers -Nikhil From: Nikhil Komawar nikhil.koma...@rackspace.com Sent: Sunday, March 8, 2015 2:40 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. Thank you for the feedback Flavio and Gary! I've noted down your concerns and will address them in a separate thread. So, I think we'd go ahead with nominations mentioned here (by Monday) and start the core-member discussion later. Thanks, -Nikhil From: Gary Kotton gkot...@vmware.com Sent: Sunday, March 8, 2015 11:45 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. On 3/8/15, 2:34 PM, Flavio Percoco fla...@redhat.com wrote: On 07/03/15 23:16 +, Nikhil Komawar wrote: Thank you for the response, Hemanth! Those are some excellent questions. In order to avoid diverging the conversation, I would like to give my general sense of direction. Please do keep in mind that a lot of these thoughts need to be better formulated, preferably on a different thread. Core-members would be generic concept unlike core-reviewers. The one important thing that this should achieve is clear understanding of the individuals (usually ones who are new or interact less often in Glance) - who actually is a Core in the program? There are a few things that can be part of their rights like being able to vote for important decisions (like the current thread), they may or may not have core-reviewer rights based on their participation area. For example, they could be security liaison or they may _officially_ do release management for the libraries without being a core-reviewer, etc. The responsibilities should complement the rights. Those are just initial thoughts and can be better formulated. I will attempt to craft out the details of the core-member concept in the near future and you all are welcome to join me in doing so. I think I misread the original proposal with ragards to core-members. As it is explained here, I'm opposed on having this. As soon as you start tagging people and adding more layers to the community, it'll be harder to manage it and more importantly it'll be more fragmented than it is, which is something I believe we don't need. Agree 100% Citing the example you mentioned in your previous email: There are a few things that can be part of their rights like being able to vote for important decisions This breaks openess and it reads like: If you're not a 'core-member', your vote won't count We've fought hard to remove all these kind of labels and exclusive rights by reducing them to the minimum, hence the core-reviewers team. Anyone should feel free to vote, speak up and most importantly, everyones opinion *must* be taken into account. I'll wait for your final proposal to give a more constructive and extended opinion based on that. Flavio Hope that answered your questions, at least for the time being! Cheers -Nikhil ━ ━━ From: Hemanth Makkapati hemanth.makkap...@rackspace.com Sent: Friday, March 6, 2015 7:15 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. I like the idea of a 'core-member'. But, how are core-members different from core-reviewers? For instance, with core-reviewers it is very clear that these are folks you would trust with merging code because they are supposed to have a good understanding of the overall project. What about core-members? Are core-members essentially just core-reviewers who somehow don't fit the criteria of core-reviewers but are good candidates nevertheless? Just trying to understand here ... no offense meant. Also, +1 to both the criteria for removing existing cores and addition of new cores. -Hemanth. ━ ━━ From: Nikhil Komawar nikhil.koma...@rackspace.com Sent: Friday, March 6, 2015 4:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel! Mike, Ian: It's a good idea to have the policy however, we need to craft one that is custom to the Glance program. It will be a bit different to ones out there as we've contributors who are dedicated to only subset of the code - for example just glance_store or python-glanceclient or metadefs. From here on, we may see that for Artifacts and other such features. It's already being observed for metadefs. While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are doing, it also makes me wonder if that's going to help us in long term. If not, then what can we do now to set
Re: [openstack-dev] [Glance] Core nominations.
Thank you for the feedback Flavio and Gary! I've noted down your concerns and will address them in a separate thread. So, I think we'd go ahead with nominations mentioned here (by Monday) and start the core-member discussion later. Thanks, -Nikhil From: Gary Kotton gkot...@vmware.com Sent: Sunday, March 8, 2015 11:45 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. On 3/8/15, 2:34 PM, Flavio Percoco fla...@redhat.com wrote: On 07/03/15 23:16 +, Nikhil Komawar wrote: Thank you for the response, Hemanth! Those are some excellent questions. In order to avoid diverging the conversation, I would like to give my general sense of direction. Please do keep in mind that a lot of these thoughts need to be better formulated, preferably on a different thread. Core-members would be generic concept unlike core-reviewers. The one important thing that this should achieve is clear understanding of the individuals (usually ones who are new or interact less often in Glance) - who actually is a Core in the program? There are a few things that can be part of their rights like being able to vote for important decisions (like the current thread), they may or may not have core-reviewer rights based on their participation area. For example, they could be security liaison or they may _officially_ do release management for the libraries without being a core-reviewer, etc. The responsibilities should complement the rights. Those are just initial thoughts and can be better formulated. I will attempt to craft out the details of the core-member concept in the near future and you all are welcome to join me in doing so. I think I misread the original proposal with ragards to core-members. As it is explained here, I'm opposed on having this. As soon as you start tagging people and adding more layers to the community, it'll be harder to manage it and more importantly it'll be more fragmented than it is, which is something I believe we don't need. Agree 100% Citing the example you mentioned in your previous email: There are a few things that can be part of their rights like being able to vote for important decisions This breaks openess and it reads like: If you're not a 'core-member', your vote won't count We've fought hard to remove all these kind of labels and exclusive rights by reducing them to the minimum, hence the core-reviewers team. Anyone should feel free to vote, speak up and most importantly, everyones opinion *must* be taken into account. I'll wait for your final proposal to give a more constructive and extended opinion based on that. Flavio Hope that answered your questions, at least for the time being! Cheers -Nikhil ━ ━━ From: Hemanth Makkapati hemanth.makkap...@rackspace.com Sent: Friday, March 6, 2015 7:15 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. I like the idea of a 'core-member'. But, how are core-members different from core-reviewers? For instance, with core-reviewers it is very clear that these are folks you would trust with merging code because they are supposed to have a good understanding of the overall project. What about core-members? Are core-members essentially just core-reviewers who somehow don't fit the criteria of core-reviewers but are good candidates nevertheless? Just trying to understand here ... no offense meant. Also, +1 to both the criteria for removing existing cores and addition of new cores. -Hemanth. ━ ━━ From: Nikhil Komawar nikhil.koma...@rackspace.com Sent: Friday, March 6, 2015 4:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel! Mike, Ian: It's a good idea to have the policy however, we need to craft one that is custom to the Glance program. It will be a bit different to ones out there as we've contributors who are dedicated to only subset of the code - for example just glance_store or python-glanceclient or metadefs. From here on, we may see that for Artifacts and other such features. It's already being observed for metadefs. While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are doing, it also makes me wonder if that's going to help us in long term. If not, then what can we do now to set a good path forward? Flavio, Erno, Malini, Louis, Mike: Drafting a guideline policy and implementing rotation based on that was my intent so that everyone is aware of the changes in the program. That would let the core reviewers know what their duties are and let non-cores know what they need to do to become cores. Moreover, I've a idea
Re: [openstack-dev] [Glance] Core nominations.
On 07/03/15 23:16 +, Nikhil Komawar wrote: Thank you for the response, Hemanth! Those are some excellent questions. In order to avoid diverging the conversation, I would like to give my general sense of direction. Please do keep in mind that a lot of these thoughts need to be better formulated, preferably on a different thread. Core-members would be generic concept unlike core-reviewers. The one important thing that this should achieve is clear understanding of the individuals (usually ones who are new or interact less often in Glance) - who actually is a Core in the program? There are a few things that can be part of their rights like being able to vote for important decisions (like the current thread), they may or may not have core-reviewer rights based on their participation area. For example, they could be security liaison or they may _officially_ do release management for the libraries without being a core-reviewer, etc. The responsibilities should complement the rights. Those are just initial thoughts and can be better formulated. I will attempt to craft out the details of the core-member concept in the near future and you all are welcome to join me in doing so. I think I misread the original proposal with ragards to core-members. As it is explained here, I'm opposed on having this. As soon as you start tagging people and adding more layers to the community, it'll be harder to manage it and more importantly it'll be more fragmented than it is, which is something I believe we don't need. Citing the example you mentioned in your previous email: There are a few things that can be part of their rights like being able to vote for important decisions This breaks openess and it reads like: If you're not a 'core-member', your vote won't count We've fought hard to remove all these kind of labels and exclusive rights by reducing them to the minimum, hence the core-reviewers team. Anyone should feel free to vote, speak up and most importantly, everyones opinion *must* be taken into account. I'll wait for your final proposal to give a more constructive and extended opinion based on that. Flavio Hope that answered your questions, at least for the time being! Cheers -Nikhil ━━━ From: Hemanth Makkapati hemanth.makkap...@rackspace.com Sent: Friday, March 6, 2015 7:15 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. I like the idea of a 'core-member'. But, how are core-members different from core-reviewers? For instance, with core-reviewers it is very clear that these are folks you would trust with merging code because they are supposed to have a good understanding of the overall project. What about core-members? Are core-members essentially just core-reviewers who somehow don't fit the criteria of core-reviewers but are good candidates nevertheless? Just trying to understand here ... no offense meant. Also, +1 to both the criteria for removing existing cores and addition of new cores. -Hemanth. ━━━ From: Nikhil Komawar nikhil.koma...@rackspace.com Sent: Friday, March 6, 2015 4:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel! Mike, Ian: It's a good idea to have the policy however, we need to craft one that is custom to the Glance program. It will be a bit different to ones out there as we've contributors who are dedicated to only subset of the code - for example just glance_store or python-glanceclient or metadefs. From here on, we may see that for Artifacts and other such features. It's already being observed for metadefs. While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are doing, it also makes me wonder if that's going to help us in long term. If not, then what can we do now to set a good path forward? Flavio, Erno, Malini, Louis, Mike: Drafting a guideline policy and implementing rotation based on that was my intent so that everyone is aware of the changes in the program. That would let the core reviewers know what their duties are and let non-cores know what they need to do to become cores. Moreover, I've a idea for proposing a core-member status for our program than just core-reviewer. That seems more applicable for a few strong regular contributors like Travis and Lakshmi who work on bug fixes, bug triaging and client improvements however, do not seem to keep momentum on reviews. The core status can affect project decisions hence, this change may be important. This process may involve some interactions with governance so, will take more time. Malini: I wish to take a strategic decision here rather an agile one. That needs a lot of brainpower before implementation
Re: [openstack-dev] [Glance] Core nominations.
On 3/8/15, 2:34 PM, Flavio Percoco fla...@redhat.com wrote: On 07/03/15 23:16 +, Nikhil Komawar wrote: Thank you for the response, Hemanth! Those are some excellent questions. In order to avoid diverging the conversation, I would like to give my general sense of direction. Please do keep in mind that a lot of these thoughts need to be better formulated, preferably on a different thread. Core-members would be generic concept unlike core-reviewers. The one important thing that this should achieve is clear understanding of the individuals (usually ones who are new or interact less often in Glance) - who actually is a Core in the program? There are a few things that can be part of their rights like being able to vote for important decisions (like the current thread), they may or may not have core-reviewer rights based on their participation area. For example, they could be security liaison or they may _officially_ do release management for the libraries without being a core-reviewer, etc. The responsibilities should complement the rights. Those are just initial thoughts and can be better formulated. I will attempt to craft out the details of the core-member concept in the near future and you all are welcome to join me in doing so. I think I misread the original proposal with ragards to core-members. As it is explained here, I'm opposed on having this. As soon as you start tagging people and adding more layers to the community, it'll be harder to manage it and more importantly it'll be more fragmented than it is, which is something I believe we don't need. Agree 100% Citing the example you mentioned in your previous email: There are a few things that can be part of their rights like being able to vote for important decisions This breaks openess and it reads like: If you're not a 'core-member', your vote won't count We've fought hard to remove all these kind of labels and exclusive rights by reducing them to the minimum, hence the core-reviewers team. Anyone should feel free to vote, speak up and most importantly, everyones opinion *must* be taken into account. I'll wait for your final proposal to give a more constructive and extended opinion based on that. Flavio Hope that answered your questions, at least for the time being! Cheers -Nikhil ━ ━━ From: Hemanth Makkapati hemanth.makkap...@rackspace.com Sent: Friday, March 6, 2015 7:15 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. I like the idea of a 'core-member'. But, how are core-members different from core-reviewers? For instance, with core-reviewers it is very clear that these are folks you would trust with merging code because they are supposed to have a good understanding of the overall project. What about core-members? Are core-members essentially just core-reviewers who somehow don't fit the criteria of core-reviewers but are good candidates nevertheless? Just trying to understand here ... no offense meant. Also, +1 to both the criteria for removing existing cores and addition of new cores. -Hemanth. ━ ━━ From: Nikhil Komawar nikhil.koma...@rackspace.com Sent: Friday, March 6, 2015 4:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel! Mike, Ian: It's a good idea to have the policy however, we need to craft one that is custom to the Glance program. It will be a bit different to ones out there as we've contributors who are dedicated to only subset of the code - for example just glance_store or python-glanceclient or metadefs. From here on, we may see that for Artifacts and other such features. It's already being observed for metadefs. While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are doing, it also makes me wonder if that's going to help us in long term. If not, then what can we do now to set a good path forward? Flavio, Erno, Malini, Louis, Mike: Drafting a guideline policy and implementing rotation based on that was my intent so that everyone is aware of the changes in the program. That would let the core reviewers know what their duties are and let non-cores know what they need to do to become cores. Moreover, I've a idea for proposing a core-member status for our program than just core-reviewer. That seems more applicable for a few strong regular contributors like Travis and Lakshmi who work on bug fixes, bug triaging and client improvements however, do not seem to keep momentum on reviews. The core status can affect project decisions hence, this change may be important. This process may involve some interactions with governance so, will take more time. Malini: I wish to take a strategic decision here
Re: [openstack-dev] [Glance] Core nominations.
Thank you for the response, Hemanth! Those are some excellent questions. In order to avoid diverging the conversation, I would like to give my general sense of direction. Please do keep in mind that a lot of these thoughts need to be better formulated, preferably on a different thread. Core-members would be generic concept unlike core-reviewers. The one important thing that this should achieve is clear understanding of the individuals (usually ones who are new or interact less often in Glance) - who actually is a Core in the program? There are a few things that can be part of their rights like being able to vote for important decisions (like the current thread), they may or may not have core-reviewer rights based on their participation area. For example, they could be security liaison or they may _officially_ do release management for the libraries without being a core-reviewer, etc. The responsibilities should complement the rights. Those are just initial thoughts and can be better formulated. I will attempt to craft out the details of the core-member concept in the near future and you all are welcome to join me in doing so. Hope that answered your questions, at least for the time being! Cheers -Nikhil From: Hemanth Makkapati hemanth.makkap...@rackspace.com Sent: Friday, March 6, 2015 7:15 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. I like the idea of a 'core-member'. But, how are core-members different from core-reviewers? For instance, with core-reviewers it is very clear that these are folks you would trust with merging code because they are supposed to have a good understanding of the overall project. What about core-members? Are core-members essentially just core-reviewers who somehow don't fit the criteria of core-reviewers but are good candidates nevertheless? Just trying to understand here ... no offense meant. Also, +1 to both the criteria for removing existing cores and addition of new cores. -Hemanth. From: Nikhil Komawar nikhil.koma...@rackspace.com Sent: Friday, March 6, 2015 4:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel! Mike, Ian: It's a good idea to have the policy however, we need to craft one that is custom to the Glance program. It will be a bit different to ones out there as we've contributors who are dedicated to only subset of the code - for example just glance_store or python-glanceclient or metadefs. From here on, we may see that for Artifacts and other such features. It's already being observed for metadefs. While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are doing, it also makes me wonder if that's going to help us in long term. If not, then what can we do now to set a good path forward? Flavio, Erno, Malini, Louis, Mike: Drafting a guideline policy and implementing rotation based on that was my intent so that everyone is aware of the changes in the program. That would let the core reviewers know what their duties are and let non-cores know what they need to do to become cores. Moreover, I've a idea for proposing a core-member status for our program than just core-reviewer. That seems more applicable for a few strong regular contributors like Travis and Lakshmi who work on bug fixes, bug triaging and client improvements however, do not seem to keep momentum on reviews. The core status can affect project decisions hence, this change may be important. This process may involve some interactions with governance so, will take more time. Malini: I wish to take a strategic decision here rather an agile one. That needs a lot of brainpower before implementation. While warning and acting is good, it seems less applicable for this case. Simply because, we need to make a positive difference in the interactions of the community and we've a chance of doing that here. Nevertheless, I do not want to block the new-core additions or ask Flavio et.al. to accommodate for the reviews that the new members would have been able to do (just kidding). Tweaking Flavio's criterion of cleaning up the list for cores who have not done any reviews in the last 2 cycles (Icehouse and Juno), I've prepared a new list below (as Flavio's list did not match up even if we take cycles to be Juno, Kilo). They can be added back to the list faster in the future if they consider contributing to Glance again. The criterion is: Reviews = 50 in combined cycles. Proposal to remove the following members(review_count) from the glance-core list: * Brian Lamar (0+15) * Brian Waldon (0+0) * Dan Prince (3+1) * Eoghan Glynn (0+3) * John Bresnahan (31+12) And we would add the following new members: * Ian
Re: [openstack-dev] [Glance] Core nominations.
I like the idea of a 'core-member'. But, how are core-members different from core-reviewers? For instance, with core-reviewers it is very clear that these are folks you would trust with merging code because they are supposed to have a good understanding of the overall project. What about core-members? Are core-members essentially just core-reviewers who somehow don't fit the criteria of core-reviewers but are good candidates nevertheless? Just trying to understand here ... no offense meant. Also, +1 to both the criteria for removing existing cores and addition of new cores. -Hemanth. From: Nikhil Komawar nikhil.koma...@rackspace.com Sent: Friday, March 6, 2015 4:04 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel! Mike, Ian: It's a good idea to have the policy however, we need to craft one that is custom to the Glance program. It will be a bit different to ones out there as we've contributors who are dedicated to only subset of the code - for example just glance_store or python-glanceclient or metadefs. From here on, we may see that for Artifacts and other such features. It's already being observed for metadefs. While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are doing, it also makes me wonder if that's going to help us in long term. If not, then what can we do now to set a good path forward? Flavio, Erno, Malini, Louis, Mike: Drafting a guideline policy and implementing rotation based on that was my intent so that everyone is aware of the changes in the program. That would let the core reviewers know what their duties are and let non-cores know what they need to do to become cores. Moreover, I've a idea for proposing a core-member status for our program than just core-reviewer. That seems more applicable for a few strong regular contributors like Travis and Lakshmi who work on bug fixes, bug triaging and client improvements however, do not seem to keep momentum on reviews. The core status can affect project decisions hence, this change may be important. This process may involve some interactions with governance so, will take more time. Malini: I wish to take a strategic decision here rather an agile one. That needs a lot of brainpower before implementation. While warning and acting is good, it seems less applicable for this case. Simply because, we need to make a positive difference in the interactions of the community and we've a chance of doing that here. Nevertheless, I do not want to block the new-core additions or ask Flavio et.al. to accommodate for the reviews that the new members would have been able to do (just kidding). Tweaking Flavio's criterion of cleaning up the list for cores who have not done any reviews in the last 2 cycles (Icehouse and Juno), I've prepared a new list below (as Flavio's list did not match up even if we take cycles to be Juno, Kilo). They can be added back to the list faster in the future if they consider contributing to Glance again. The criterion is: Reviews = 50 in combined cycles. Proposal to remove the following members(review_count) from the glance-core list: * Brian Lamar (0+15) * Brian Waldon (0+0) * Dan Prince (3+1) * Eoghan Glynn (0+3) * John Bresnahan (31+12) And we would add the following new members: * Ian Cordasco * Louis Taylor * Mike Fedosin * Hemanth Makkapati This way we've a first round of consolidation done. It must be evident that the list-cleanup proposed above is not comprehensive with regards to who is truly inactive. Thus, misses out on a few names due to lack of established criterion. We can do more about rotation in the following weeks. Hope it works! Regards, -Nikhil From: Kyle Mestery mest...@mestery.com Sent: Friday, March 6, 2015 12:45 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. On Fri, Mar 6, 2015 at 11:40 AM, Ian Cordasco ian.corda...@rackspace.commailto:ian.corda...@rackspace.com wrote: I like that idea. Can you start it out with Nova or Neutron's guidelines? FYI, the core reviewer guidelines for Neutron are in-tree now [1], along with all of our other policies around operating in Neutron [2]. [1] https://github.com/openstack/neutron/blob/master/doc/source/policies/core-reviewers.rst [2] https://github.com/openstack/neutron/tree/master/doc/source/policies On 3/5/15, 17:38, Mikhail Fedosin mfedo...@mirantis.commailto:mfedo...@mirantis.com wrote: I think yes, it does. But I mean that now we're writing a document called Glance Review Guidelines https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5R JabsI/edit?usp=sharing https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw
Re: [openstack-dev] [Glance] Core nominations.
On Fri, Mar 6, 2015 at 11:40 AM, Ian Cordasco ian.corda...@rackspace.com wrote: I like that idea. Can you start it out with Nova or Neutron’s guidelines? FYI, the core reviewer guidelines for Neutron are in-tree now [1], along with all of our other policies around operating in Neutron [2]. [1] https://github.com/openstack/neutron/blob/master/doc/source/policies/core-reviewers.rst [2] https://github.com/openstack/neutron/tree/master/doc/source/policies On 3/5/15, 17:38, Mikhail Fedosin mfedo...@mirantis.com wrote: I think yes, it does. But I mean that now we're writing a document called Glance Review Guidelines https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5R JabsI/edit?usp=sharing https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5 RJabsI/edit?usp=sharing and it has a section For cores. It's easy to include some concrete rules there to add more clarity. 2015-03-05 17:46 GMT+03:00 Ihar Hrachyshka ihrac...@redhat.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/05/2015 11:35 AM, Mikhail Fedosin wrote: Yes, it's absolutely right. For example, Nova and Neutron have official rules for that: https://wiki.openstack.org/wiki/Nova/CoreTeam where it says: A member of the team may be removed at any time by the PTL. This is typically due to a drop off of involvement by the member such that they are no longer meeting expectations to maintain team membership. https://wiki.openstack.org/wiki/NeutronCore https://wiki.openstack.org/wiki/NeutronCore The PTL may remove a member from neutron-core at any time. Typically when a member has decreased their involvement with the project through a drop in reviews and participation in general project development, the PTL will propose their removal and remove them. Members who have previously been core may be fast-tracked back into core if their involvement picks back up So, as Louis has mentioned, it's a routine work, and why should we be any different? Also, I suggest to write the same wiki document for Glance to prevent these issues in the future. Does the rule belong to e.g. governance repo? It seems like a sane requirement for core *reviewers* to actually review code, no? Or are there any projects that would not like to adopt such a rule formally? /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU+GxdAAoJEC5aWaUY1u579mEIAMN/wucsahaZ0yMT2/eo8t05 rIWI+lBLjNueWJgB+zNbVlVcsKBZ/hl4J0O3eE65RtlTS5Rta5hv0ymyRL1nnUZH g/tL3ogEF0SsSBkiavVh3klGmUwsvQ+ygPN5rVgnbiJ+uO555EPlbiHwZHbcjBoI lyUjIhWzUCX26wq7mgiTsY858UgdEt3urVHD9jTE2WNszMRLXQ7vsoAik9xDfISz E0eZ8WVQKlNHNox0UoKbobdb3YDhmY3Ahp9Fj2cT1IScyQGORnm0hXV3+pRdWNhD 1M/gDwAf97F1lfNxPpy4JCGutbe5zoPQYLpJExzaXkqqARxUnwhB1gZ9lEG8l2o= =lcLY -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Core nominations.
I like that idea. Can you start it out with Nova or Neutron’s guidelines? On 3/5/15, 17:38, Mikhail Fedosin mfedo...@mirantis.com wrote: I think yes, it does. But I mean that now we're writing a document called Glance Review Guidelines https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5R JabsI/edit?usp=sharing https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5 RJabsI/edit?usp=sharing and it has a section For cores. It's easy to include some concrete rules there to add more clarity. 2015-03-05 17:46 GMT+03:00 Ihar Hrachyshka ihrac...@redhat.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/05/2015 11:35 AM, Mikhail Fedosin wrote: Yes, it's absolutely right. For example, Nova and Neutron have official rules for that: https://wiki.openstack.org/wiki/Nova/CoreTeam where it says: A member of the team may be removed at any time by the PTL. This is typically due to a drop off of involvement by the member such that they are no longer meeting expectations to maintain team membership. https://wiki.openstack.org/wiki/NeutronCore https://wiki.openstack.org/wiki/NeutronCore The PTL may remove a member from neutron-core at any time. Typically when a member has decreased their involvement with the project through a drop in reviews and participation in general project development, the PTL will propose their removal and remove them. Members who have previously been core may be fast-tracked back into core if their involvement picks back up So, as Louis has mentioned, it's a routine work, and why should we be any different? Also, I suggest to write the same wiki document for Glance to prevent these issues in the future. Does the rule belong to e.g. governance repo? It seems like a sane requirement for core *reviewers* to actually review code, no? Or are there any projects that would not like to adopt such a rule formally? /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU+GxdAAoJEC5aWaUY1u579mEIAMN/wucsahaZ0yMT2/eo8t05 rIWI+lBLjNueWJgB+zNbVlVcsKBZ/hl4J0O3eE65RtlTS5Rta5hv0ymyRL1nnUZH g/tL3ogEF0SsSBkiavVh3klGmUwsvQ+ygPN5rVgnbiJ+uO555EPlbiHwZHbcjBoI lyUjIhWzUCX26wq7mgiTsY858UgdEt3urVHD9jTE2WNszMRLXQ7vsoAik9xDfISz E0eZ8WVQKlNHNox0UoKbobdb3YDhmY3Ahp9Fj2cT1IScyQGORnm0hXV3+pRdWNhD 1M/gDwAf97F1lfNxPpy4JCGutbe5zoPQYLpJExzaXkqqARxUnwhB1gZ9lEG8l2o= =lcLY -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Core nominations.
Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel! Mike, Ian: It's a good idea to have the policy however, we need to craft one that is custom to the Glance program. It will be a bit different to ones out there as we've contributors who are dedicated to only subset of the code - for example just glance_store or python-glanceclient or metadefs. From here on, we may see that for Artifacts and other such features. It's already being observed for metadefs. While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are doing, it also makes me wonder if that's going to help us in long term. If not, then what can we do now to set a good path forward? Flavio, Erno, Malini, Louis, Mike: Drafting a guideline policy and implementing rotation based on that was my intent so that everyone is aware of the changes in the program. That would let the core reviewers know what their duties are and let non-cores know what they need to do to become cores. Moreover, I've a idea for proposing a core-member status for our program than just core-reviewer. That seems more applicable for a few strong regular contributors like Travis and Lakshmi who work on bug fixes, bug triaging and client improvements however, do not seem to keep momentum on reviews. The core status can affect project decisions hence, this change may be important. This process may involve some interactions with governance so, will take more time. Malini: I wish to take a strategic decision here rather an agile one. That needs a lot of brainpower before implementation. While warning and acting is good, it seems less applicable for this case. Simply because, we need to make a positive difference in the interactions of the community and we've a chance of doing that here. Nevertheless, I do not want to block the new-core additions or ask Flavio et.al. to accommodate for the reviews that the new members would have been able to do (just kidding). Tweaking Flavio's criterion of cleaning up the list for cores who have not done any reviews in the last 2 cycles (Icehouse and Juno), I've prepared a new list below (as Flavio's list did not match up even if we take cycles to be Juno, Kilo). They can be added back to the list faster in the future if they consider contributing to Glance again. The criterion is: Reviews = 50 in combined cycles. Proposal to remove the following members(review_count) from the glance-core list: * Brian Lamar (0+15) * Brian Waldon (0+0) * Dan Prince (3+1) * Eoghan Glynn (0+3) * John Bresnahan (31+12) And we would add the following new members: * Ian Cordasco * Louis Taylor * Mike Fedosin * Hemanth Makkapati This way we've a first round of consolidation done. It must be evident that the list-cleanup proposed above is not comprehensive with regards to who is truly inactive. Thus, misses out on a few names due to lack of established criterion. We can do more about rotation in the following weeks. Hope it works! Regards, -Nikhil From: Kyle Mestery mest...@mestery.com Sent: Friday, March 6, 2015 12:45 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. On Fri, Mar 6, 2015 at 11:40 AM, Ian Cordasco ian.corda...@rackspace.commailto:ian.corda...@rackspace.com wrote: I like that idea. Can you start it out with Nova or Neutron’s guidelines? FYI, the core reviewer guidelines for Neutron are in-tree now [1], along with all of our other policies around operating in Neutron [2]. [1] https://github.com/openstack/neutron/blob/master/doc/source/policies/core-reviewers.rst [2] https://github.com/openstack/neutron/tree/master/doc/source/policies On 3/5/15, 17:38, Mikhail Fedosin mfedo...@mirantis.commailto:mfedo...@mirantis.com wrote: I think yes, it does. But I mean that now we're writing a document called Glance Review Guidelines https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5R JabsI/edit?usp=sharing https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5 RJabsI/edit?usp=sharing and it has a section For cores. It's easy to include some concrete rules there to add more clarity. 2015-03-05 17:46 GMT+03:00 Ihar Hrachyshka ihrac...@redhat.commailto:ihrac...@redhat.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/05/2015 11:35 AM, Mikhail Fedosin wrote: Yes, it's absolutely right. For example, Nova and Neutron have official rules for that: https://wiki.openstack.org/wiki/Nova/CoreTeam where it says: A member of the team may be removed at any time by the PTL. This is typically due to a drop off of involvement by the member such that they are no longer meeting expectations to maintain team membership. https://wiki.openstack.org/wiki/NeutronCore https://wiki.openstack.org/wiki/NeutronCore The PTL may remove a member from neutron-core at any time. Typically when a member
Re: [openstack-dev] [Glance] Core nominations.
On 3/6/15, 15:04, Nikhil Komawar nikhil.koma...@rackspace.com wrote: Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel! Mike, Ian: It's a good idea to have the policy however, we need to craft one that is custom to the Glance program. It will be a bit different to ones out there as we've contributors who are dedicated to only subset of the code - for example just glance_store or python-glanceclient or metadefs. From here on, we may see that for Artifacts and other such features. It's already being observed for metadefs. While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are doing, it also makes me wonder if that's going to help us in long term. If not, then what can we do now to set a good path forward? Flavio, Erno, Malini, Louis, Mike: Drafting a guideline policy and implementing rotation based on that was my intent so that everyone is aware of the changes in the program. That would let the core reviewers know what their duties are and let non-cores know what they need to do to become cores. Moreover, I've a idea for proposing a core-member status for our program than just core-reviewer. That seems more applicable for a few strong regular contributors like Travis and Lakshmi who work on bug fixes, bug triaging and client improvements however, do not seem to keep momentum on reviews. The core status can affect project decisions hence, this change may be important. This process may involve some interactions with governance so, will take more time. Malini: I wish to take a strategic decision here rather an agile one. That needs a lot of brainpower before implementation. While warning and acting is good, it seems less applicable for this case. Simply because, we need to make a positive difference in the interactions of the community and we've a chance of doing that here. Nevertheless, I do not want to block the new-core additions or ask Flavio et.al. to accommodate for the reviews that the new members would have been able to do (just kidding). Tweaking Flavio's criterion of cleaning up the list for cores who have not done any reviews in the last 2 cycles (Icehouse and Juno), I've prepared a new list below (as Flavio's list did not match up even if we take cycles to be Juno, Kilo). They can be added back to the list faster in the future if they consider contributing to Glance again. The criterion is: Reviews = 50 in combined cycles. Proposal to remove the following members(review_count) from the glance-core list: * Brian Lamar (0+15) * Brian Waldon (0+0) * Dan Prince (3+1) * Eoghan Glynn (0+3) * John Bresnahan (31+12) +1 to removing inactive core reviewers. And we would add the following new members: * Ian Cordasco Who’s that guy? Why is he being nominated? =P * Louis Taylor * Mike Fedosin * Hemanth Makkapati +1 to these three being added though. This way we've a first round of consolidation done. It must be evident that the list-cleanup proposed above is not comprehensive with regards to who is truly inactive. Thus, misses out on a few names due to lack of established criterion. We can do more about rotation in the following weeks. Hope it works! Regards, -Nikhil From: Kyle Mestery mest...@mestery.com Sent: Friday, March 6, 2015 12:45 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. On Fri, Mar 6, 2015 at 11:40 AM, Ian Cordasco ian.corda...@rackspace.com wrote: I like that idea. Can you start it out with Nova or Neutron’s guidelines? FYI, the core reviewer guidelines for Neutron are in-tree now [1], along with all of our other policies around operating in Neutron [2]. [1] https://github.com/openstack/neutron/blob/master/doc/source/policies/core- reviewers.rst https://github.com/openstack/neutron/blob/master/doc/source/policies/core -reviewers.rst [2] https://github.com/openstack/neutron/tree/master/doc/source/policies https://github.com/openstack/neutron/tree/master/doc/source/policies On 3/5/15, 17:38, Mikhail Fedosin mfedo...@mirantis.com wrote: I think yes, it does. But I mean that now we're writing a document called Glance Review Guidelines https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5 R JabsI/edit?usp=sharing https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_ 5 RJabsI/edit?usp=sharing and it has a section For cores. It's easy to include some concrete rules there to add more clarity. 2015-03-05 17:46 GMT+03:00 Ihar Hrachyshka ihrac...@redhat.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/05/2015 11:35 AM, Mikhail Fedosin wrote: Yes, it's absolutely right. For example, Nova and Neutron have official rules for that: https://wiki.openstack.org/wiki/Nova/CoreTeam where it says: A member of the team may be removed at any time by the PTL. This is typically due to a drop off of involvement by the member
Re: [openstack-dev] [Glance] Core nominations.
On 06/03/15 21:09 +, Ian Cordasco wrote: On 3/6/15, 15:04, Nikhil Komawar nikhil.koma...@rackspace.com wrote: Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel! Mike, Ian: It's a good idea to have the policy however, we need to craft one that is custom to the Glance program. It will be a bit different to ones out there as we've contributors who are dedicated to only subset of the code - for example just glance_store or python-glanceclient or metadefs. From here on, we may see that for Artifacts and other such features. It's already being observed for metadefs. While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are doing, it also makes me wonder if that's going to help us in long term. If not, then what can we do now to set a good path forward? Flavio, Erno, Malini, Louis, Mike: Drafting a guideline policy and implementing rotation based on that was my intent so that everyone is aware of the changes in the program. That would let the core reviewers know what their duties are and let non-cores know what they need to do to become cores. Moreover, I've a idea for proposing a core-member status for our program than just core-reviewer. That seems more applicable for a few strong regular contributors like Travis and Lakshmi who work on bug fixes, bug triaging and client improvements however, do not seem to keep momentum on reviews. The core status can affect project decisions hence, this change may be important. This process may involve some interactions with governance so, will take more time. Malini: I wish to take a strategic decision here rather an agile one. That needs a lot of brainpower before implementation. While warning and acting is good, it seems less applicable for this case. Simply because, we need to make a positive difference in the interactions of the community and we've a chance of doing that here. Nevertheless, I do not want to block the new-core additions or ask Flavio et.al. to accommodate for the reviews that the new members would have been able to do (just kidding). Tweaking Flavio's criterion of cleaning up the list for cores who have not done any reviews in the last 2 cycles (Icehouse and Juno), I've prepared a new list below (as Flavio's list did not match up even if we take cycles to be Juno, Kilo). They can be added back to the list faster in the future if they consider contributing to Glance again. The criterion is: Reviews = 50 in combined cycles. Proposal to remove the following members(review_count) from the glance-core list: * Brian Lamar (0+15) * Brian Waldon (0+0) * Dan Prince (3+1) * Eoghan Glynn (0+3) * John Bresnahan (31+12) +1 to removing inactive core reviewers. +2 this is a good start. And we would add the following new members: * Ian Cordasco Who’s that guy? Why is he being nominated? =P Oh dear... * Louis Taylor * Mike Fedosin * Hemanth Makkapati +1 to these three being added though. +2 This way we've a first round of consolidation done. It must be evident that the list-cleanup proposed above is not comprehensive with regards to who is truly inactive. Thus, misses out on a few names due to lack of established criterion. We can do more about rotation in the following weeks. Hope it works! Thanks for taking care of this, Flavio Regards, -Nikhil From: Kyle Mestery mest...@mestery.com Sent: Friday, March 6, 2015 12:45 PM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. On Fri, Mar 6, 2015 at 11:40 AM, Ian Cordasco ian.corda...@rackspace.com wrote: I like that idea. Can you start it out with Nova or Neutron’s guidelines? FYI, the core reviewer guidelines for Neutron are in-tree now [1], along with all of our other policies around operating in Neutron [2]. [1] https://github.com/openstack/neutron/blob/master/doc/source/policies/core- reviewers.rst https://github.com/openstack/neutron/blob/master/doc/source/policies/core -reviewers.rst [2] https://github.com/openstack/neutron/tree/master/doc/source/policies https://github.com/openstack/neutron/tree/master/doc/source/policies On 3/5/15, 17:38, Mikhail Fedosin mfedo...@mirantis.com wrote: I think yes, it does. But I mean that now we're writing a document called Glance Review Guidelines https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5 R JabsI/edit?usp=sharing https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_ 5 RJabsI/edit?usp=sharing and it has a section For cores. It's easy to include some concrete rules there to add more clarity. 2015-03-05 17:46 GMT+03:00 Ihar Hrachyshka ihrac...@redhat.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/05/2015 11:35 AM, Mikhail Fedosin wrote: Yes, it's absolutely right. For example, Nova and Neutron have official rules for that: https://wiki.openstack.org/wiki/Nova/CoreTeam where it says: A member
Re: [openstack-dev] [Glance] Core nominations.
I think yes, it does. But I mean that now we're writing a document called Glance Review Guidelines https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5RJabsI/edit?usp=sharing and it has a section For cores. It's easy to include some concrete rules there to add more clarity. 2015-03-05 17:46 GMT+03:00 Ihar Hrachyshka ihrac...@redhat.com: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/05/2015 11:35 AM, Mikhail Fedosin wrote: Yes, it's absolutely right. For example, Nova and Neutron have official rules for that: https://wiki.openstack.org/wiki/Nova/CoreTeam where it says: A member of the team may be removed at any time by the PTL. This is typically due to a drop off of involvement by the member such that they are no longer meeting expectations to maintain team membership. https://wiki.openstack.org/wiki/NeutronCore The PTL may remove a member from neutron-core at any time. Typically when a member has decreased their involvement with the project through a drop in reviews and participation in general project development, the PTL will propose their removal and remove them. Members who have previously been core may be fast-tracked back into core if their involvement picks back up So, as Louis has mentioned, it's a routine work, and why should we be any different? Also, I suggest to write the same wiki document for Glance to prevent these issues in the future. Does the rule belong to e.g. governance repo? It seems like a sane requirement for core *reviewers* to actually review code, no? Or are there any projects that would not like to adopt such a rule formally? /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU+GxdAAoJEC5aWaUY1u579mEIAMN/wucsahaZ0yMT2/eo8t05 rIWI+lBLjNueWJgB+zNbVlVcsKBZ/hl4J0O3eE65RtlTS5Rta5hv0ymyRL1nnUZH g/tL3ogEF0SsSBkiavVh3klGmUwsvQ+ygPN5rVgnbiJ+uO555EPlbiHwZHbcjBoI lyUjIhWzUCX26wq7mgiTsY858UgdEt3urVHD9jTE2WNszMRLXQ7vsoAik9xDfISz E0eZ8WVQKlNHNox0UoKbobdb3YDhmY3Ahp9Fj2cT1IScyQGORnm0hXV3+pRdWNhD 1M/gDwAf97F1lfNxPpy4JCGutbe5zoPQYLpJExzaXkqqARxUnwhB1gZ9lEG8l2o= =lcLY -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Core nominations.
On 3/4/15 11:31 PM, Thierry Carrez wrote: Flavio Percoco wrote: [...] I personally don't think adding new cores without cleaning up that list is something healthy for our community, which is what we're trying to improve here. Therefore I'm still -2-W on adding new folks without removing non-active core members. It's also *extremely* easy to add back long-inactive members if they happen to come back. Again, core is not a badge, it corresponds to a set of duties. If some people don't fill those duties anymore, it's better to remove them than to keep them around: it maintains the standards of expected review activity fore core reviewers at a high level. While I long to have more time to properly contribute to glance and I miss the time when I did, as an inactive core member I also agree that rotation makes sense. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Core nominations.
Flavio Percoco wrote: [...] I personally don't think adding new cores without cleaning up that list is something healthy for our community, which is what we're trying to improve here. Therefore I'm still -2-W on adding new folks without removing non-active core members. It's also *extremely* easy to add back long-inactive members if they happen to come back. Again, core is not a badge, it corresponds to a set of duties. If some people don't fill those duties anymore, it's better to remove them than to keep them around: it maintains the standards of expected review activity fore core reviewers at a high level. -- Thierry Carrez (ttx) signature.asc Description: OpenPGP digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Core nominations.
Yes, it's absolutely right. For example, Nova and Neutron have official rules for that: https://wiki.openstack.org/wiki/Nova/CoreTeam where it says: A member of the team may be removed at any time by the PTL. This is typically due to a drop off of involvement by the member such that they are no longer meeting expectations to maintain team membership. https://wiki.openstack.org/wiki/NeutronCore The PTL may remove a member from neutron-core at any time. Typically when a member has decreased their involvement with the project through a drop in reviews and participation in general project development, the PTL will propose their removal and remove them. Members who have previously been core may be fast-tracked back into core if their involvement picks back up So, as Louis has mentioned, it's a routine work, and why should we be any different? Also, I suggest to write the same wiki document for Glance to prevent these issues in the future. Best, Mike 2015-03-05 12:31 GMT+03:00 Thierry Carrez thie...@openstack.org: Flavio Percoco wrote: [...] I personally don't think adding new cores without cleaning up that list is something healthy for our community, which is what we're trying to improve here. Therefore I'm still -2-W on adding new folks without removing non-active core members. It's also *extremely* easy to add back long-inactive members if they happen to come back. Again, core is not a badge, it corresponds to a set of duties. If some people don't fill those duties anymore, it's better to remove them than to keep them around: it maintains the standards of expected review activity fore core reviewers at a high level. -- Thierry Carrez (ttx) __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Core nominations.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/05/2015 11:35 AM, Mikhail Fedosin wrote: Yes, it's absolutely right. For example, Nova and Neutron have official rules for that: https://wiki.openstack.org/wiki/Nova/CoreTeam where it says: A member of the team may be removed at any time by the PTL. This is typically due to a drop off of involvement by the member such that they are no longer meeting expectations to maintain team membership. https://wiki.openstack.org/wiki/NeutronCore The PTL may remove a member from neutron-core at any time. Typically when a member has decreased their involvement with the project through a drop in reviews and participation in general project development, the PTL will propose their removal and remove them. Members who have previously been core may be fast-tracked back into core if their involvement picks back up So, as Louis has mentioned, it's a routine work, and why should we be any different? Also, I suggest to write the same wiki document for Glance to prevent these issues in the future. Does the rule belong to e.g. governance repo? It seems like a sane requirement for core *reviewers* to actually review code, no? Or are there any projects that would not like to adopt such a rule formally? /Ihar -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJU+GxdAAoJEC5aWaUY1u579mEIAMN/wucsahaZ0yMT2/eo8t05 rIWI+lBLjNueWJgB+zNbVlVcsKBZ/hl4J0O3eE65RtlTS5Rta5hv0ymyRL1nnUZH g/tL3ogEF0SsSBkiavVh3klGmUwsvQ+ygPN5rVgnbiJ+uO555EPlbiHwZHbcjBoI lyUjIhWzUCX26wq7mgiTsY858UgdEt3urVHD9jTE2WNszMRLXQ7vsoAik9xDfISz E0eZ8WVQKlNHNox0UoKbobdb3YDhmY3Ahp9Fj2cT1IScyQGORnm0hXV3+pRdWNhD 1M/gDwAf97F1lfNxPpy4JCGutbe5zoPQYLpJExzaXkqqARxUnwhB1gZ9lEG8l2o= =lcLY -END PGP SIGNATURE- __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Core nominations.
Flavio, I concur, for a lively committee need active core reviewers. Core status is an honor and responsibility. I agree it’s a good idea to replace inactive cores, no offense, priorities and focus of developers change, and should they want to return, can be fast pathed then. Regards Malini -Original Message- From: Flavio Percoco [mailto:fla...@redhat.com] Sent: Wednesday, March 04, 2015 4:09 AM To: OpenStack Development Mailing List (not for usage questions) Cc: krag...@gmail.com Subject: Re: [openstack-dev] [Glance] Core nominations. On 03/03/15 16:10 +, Nikhil Komawar wrote: If it was not clear in my previous message, I would like to again emphasize that I truly appreciate the vigor and intent behind Flavio's proposal. We need to be proactive and keep making the community better in such regards. However, at the same time we need to act fairly, with patience and have a friendly strategy for doing the same (thus maintaining a good balance in our progress). I should probably respond to another thread on ML mentioning my opinion that the community's success depends on trust and empathy and everyone's intent as well as effort in maintaining these principles. Without them, it will not take very long to make the situation chaotic. I'm sorry but no. I don't think there's anything that requires extra patience than 2 (or even more) cycles without provaiding reviews or even any kind of active contribution. I personally don't think adding new cores without cleaning up that list is something healthy for our community, which is what we're trying to improve here. Therefore I'm still -2-W on adding new folks without removing non-active core members. The questions I poised are still unanswered: There are a few members who have been relatively inactive this cycle in terms of reviews and have been missed in Flavio's list (That list is not comprehensive). On what basis have some of them been missed out and if we do not have strong reason, are we being fair? Again, I would like to emphasize that, cleaning of the list in such proportions at this point of time does NOT look OK strategy to me. The list contains the names of ppl that have not provided *any* kind of review in the last 2 cycles. If there are folks in that list that you think shouldn't be there, please, bring them up now. If there are folks you think *should* be in that list, please, bring them on now. There's nothing unpolite in what's being discussed here. The proposal is based on the facts that these folks seem to be focused in different things now and that's perfectly fine. As I mentioned in my first email, we're not questioning their knowledge but their focus and they are more than welcome to join again. I do not think *counting* the stats of everyone makes sense here, we're not competing on who reviews more patches. That's nonsense. We're just trying to keep the list of folks that will have the power to approve patches short. To answer your concerns: (Why was this not proposed earlier in the cycle?) [snip] ? The essence of the matter is: We need to change the dynamics slowly and with patience for maintaining a good balance. As I mentioned above, I don't think we're being impatient. As a matter of fact, some of this folks haven't been around in *years* so, pardon my stubborness but I believe we have been way to patient and I'd have loved this folks to step down themselves. I infinitely thank these folks past work and efforts (and hopefully future works too) but I think it's time for us to have a clearer view of who's working in the project. As a last note, it's really important to have the list of members updated, some folks rely on that to know who are the contacts for some projects. Flavio Best, -Nikhil ━━━ From: Kuvaja, Erno kuv...@hp.com Sent: Tuesday, March 3, 2015 9:48 AM To: OpenStack Development Mailing List (not for usage questions); Daniel P. Berrange Cc: krag...@gmail.com Subject: Re: [openstack-dev] [Glance] Core nominations. Nikhil, If I recall correctly this matter was discussed last time at the start of the L-cycle and at that time we agreed to see if there is change of pattern to later of the cycle. There has not been one and I do not see reason to postpone this again, just for the courtesy of it in the hopes some of our older cores happens to make review or two. I think Flavio’s proposal combined with the new members would be the right way to reinforce to momentum we’ve gained in Glance over past few months. I think it’s also the right message to send out for the new cores (including you and myself ;) ) that activity is the key to maintain such status. - Erno From: Nikhil Komawar [mailto:nikhil.koma...@rackspace.com] Sent: 03 March 2015 04:47 To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage questions) Cc: krag...@gmail.com Subject: Re
Re: [openstack-dev] [Glance] Core nominations.
On 03/03/15 16:10 +, Nikhil Komawar wrote: If it was not clear in my previous message, I would like to again emphasize that I truly appreciate the vigor and intent behind Flavio's proposal. We need to be proactive and keep making the community better in such regards. However, at the same time we need to act fairly, with patience and have a friendly strategy for doing the same (thus maintaining a good balance in our progress). I should probably respond to another thread on ML mentioning my opinion that the community's success depends on trust and empathy and everyone's intent as well as effort in maintaining these principles. Without them, it will not take very long to make the situation chaotic. I'm sorry but no. I don't think there's anything that requires extra patience than 2 (or even more) cycles without provaiding reviews or even any kind of active contribution. I personally don't think adding new cores without cleaning up that list is something healthy for our community, which is what we're trying to improve here. Therefore I'm still -2-W on adding new folks without removing non-active core members. The questions I poised are still unanswered: There are a few members who have been relatively inactive this cycle in terms of reviews and have been missed in Flavio's list (That list is not comprehensive). On what basis have some of them been missed out and if we do not have strong reason, are we being fair? Again, I would like to emphasize that, cleaning of the list in such proportions at this point of time does NOT look OK strategy to me. The list contains the names of ppl that have not provided *any* kind of review in the last 2 cycles. If there are folks in that list that you think shouldn't be there, please, bring them up now. If there are folks you think *should* be in that list, please, bring them on now. There's nothing unpolite in what's being discussed here. The proposal is based on the facts that these folks seem to be focused in different things now and that's perfectly fine. As I mentioned in my first email, we're not questioning their knowledge but their focus and they are more than welcome to join again. I do not think *counting* the stats of everyone makes sense here, we're not competing on who reviews more patches. That's nonsense. We're just trying to keep the list of folks that will have the power to approve patches short. To answer your concerns: (Why was this not proposed earlier in the cycle?) [snip] ? The essence of the matter is: We need to change the dynamics slowly and with patience for maintaining a good balance. As I mentioned above, I don't think we're being impatient. As a matter of fact, some of this folks haven't been around in *years* so, pardon my stubborness but I believe we have been way to patient and I'd have loved this folks to step down themselves. I infinitely thank these folks past work and efforts (and hopefully future works too) but I think it's time for us to have a clearer view of who's working in the project. As a last note, it's really important to have the list of members updated, some folks rely on that to know who are the contacts for some projects. Flavio Best, -Nikhil ━━━ From: Kuvaja, Erno kuv...@hp.com Sent: Tuesday, March 3, 2015 9:48 AM To: OpenStack Development Mailing List (not for usage questions); Daniel P. Berrange Cc: krag...@gmail.com Subject: Re: [openstack-dev] [Glance] Core nominations. Nikhil, If I recall correctly this matter was discussed last time at the start of the L-cycle and at that time we agreed to see if there is change of pattern to later of the cycle. There has not been one and I do not see reason to postpone this again, just for the courtesy of it in the hopes some of our older cores happens to make review or two. I think Flavio’s proposal combined with the new members would be the right way to reinforce to momentum we’ve gained in Glance over past few months. I think it’s also the right message to send out for the new cores (including you and myself ;) ) that activity is the key to maintain such status. - Erno From: Nikhil Komawar [mailto:nikhil.koma...@rackspace.com] Sent: 03 March 2015 04:47 To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage questions) Cc: krag...@gmail.com Subject: Re: [openstack-dev] [Glance] Core nominations. Hi all, After having thoroughly thought about the proposed rotation and evaluating the pros and cons of the same at this point of time, I would like to make an alternate proposal. New Proposal: 1. We should go ahead with adding more core members now. 2. Come up with a plan and give additional notice for the rotation. Get it implemented one month into Liberty. Reasoning: Traditionally, Glance program did not implement rotation. This was probably with good reason as the program was small and the developers were working closely
Re: [openstack-dev] [Glance] Core nominations.
On Wed, Mar 04, 2015 at 07:38:42AM -0430, Flavio Percoco wrote: I'm sorry but no. I don't think there's anything that requires extra patience than 2 (or even more) cycles without provaiding reviews or even any kind of active contribution. I personally don't think adding new cores without cleaning up that list is something healthy for our community, which is what we're trying to improve here. Therefore I'm still -2-W on adding new folks without removing non-active core members. The questions I poised are still unanswered: There are a few members who have been relatively inactive this cycle in terms of reviews and have been missed in Flavio's list (That list is not comprehensive). On what basis have some of them been missed out and if we do not have strong reason, are we being fair? Again, I would like to emphasize that, cleaning of the list in such proportions at this point of time does NOT look OK strategy to me. The list contains the names of ppl that have not provided *any* kind of review in the last 2 cycles. If there are folks in that list that you think shouldn't be there, please, bring them up now. If there are folks you think *should* be in that list, please, bring them on now. There's nothing unpolite in what's being discussed here. The proposal is based on the facts that these folks seem to be focused in different things now and that's perfectly fine. As I mentioned in my first email, we're not questioning their knowledge but their focus and they are more than welcome to join again. I do not think *counting* the stats of everyone makes sense here, we're not competing on who reviews more patches. That's nonsense. We're just trying to keep the list of folks that will have the power to approve patches short. To answer your concerns: (Why was this not proposed earlier in the cycle?) [snip] ? The essence of the matter is: We need to change the dynamics slowly and with patience for maintaining a good balance. As I mentioned above, I don't think we're being impatient. As a matter of fact, some of this folks haven't been around in *years* so, pardon my stubborness but I believe we have been way to patient and I'd have loved this folks to step down themselves. I infinitely thank these folks past work and efforts (and hopefully future works too) but I think it's time for us to have a clearer view of who's working in the project. As a last note, it's really important to have the list of members updated, some folks rely on that to know who are the contacts for some projects. As one of the people in the proposed group of cores, I agree with Flavio. This is something routinely done in other projects, and I don't see why we should be any different. Louis signature.asc Description: Digital signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Core nominations.
From: Nikhil Komawar [mailto:nikhil.koma...@rackspace.com] Sent: Tuesday, March 03, 2015 4:10 PM To: OpenStack Development Mailing List (not for usage questions); Daniel P. Berrange Cc: krag...@gmail.com Subject: Re: [openstack-dev] [Glance] Core nominations. If it was not clear in my previous message, I would like to again emphasize that I truly appreciate the vigor and intent behind Flavio's proposal. We need to be proactive and keep making the community better in such regards. However, at the same time we need to act fairly, with patience and have a friendly strategy for doing the same (thus maintaining a good balance in our progress). I should probably respond to another thread on ML mentioning my opinion that the community's success depends on trust and empathy and everyone's intent as well as effort in maintaining these principles. Without them, it will not take very long to make the situation chaotic. snip Hence, I think coming with a good plan during the feature freeze period including when and how are we going to implement it, when would be a final draft of cores to be rotated be published, etc. questions would be answered with _patience_ and input from other cores. We would have a plan in K so, that WOULD be a step forward as discussed in the beginning and be implemented in L, ensuring out empathetic stand. The essence of the matter is: We need to change the dynamics slowly and with patience for maintaining a good balance. Based on the above I must vote -- for adding 4 new cores without doing the housekeeping. To maintain good balance one needs to achieve that first and I do not see how the proposal is slow and patient towards that goal. - Erno Best, -Nikhil __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Glance] Core nominations.
If it was not clear in my previous message, I would like to again emphasize that I truly appreciate the vigor and intent behind Flavio's proposal. We need to be proactive and keep making the community better in such regards. However, at the same time we need to act fairly, with patience and have a friendly strategy for doing the same (thus maintaining a good balance in our progress). I should probably respond to another thread on ML mentioning my opinion that the community's success depends on trust and empathy and everyone's intent as well as effort in maintaining these principles. Without them, it will not take very long to make the situation chaotic. The questions I poised are still unanswered: There are a few members who have been relatively inactive this cycle in terms of reviews and have been missed in Flavio's list (That list is not comprehensive). On what basis have some of them been missed out and if we do not have strong reason, are we being fair? Again, I would like to emphasize that, cleaning of the list in such proportions at this point of time does NOT look OK strategy to me. To answer your concerns: (Why was this not proposed earlier in the cycle?) There are multiple reasons which are hard to be put in words because they are subtle and guided the momentum at that point of time. I agree that this was indeed proposed in the beginning of K cycle however, with less enthusiasm from all the members. Only a select few were insistent and democratically, it got deprioritized. There were other major concerns to be handled like position of the community members on some of the newer features. That in turn would have guided, the commitment from some of the members to the Glance program (probably based on their other priorities). Hence, I think coming with a good plan during the feature freeze period including when and how are we going to implement it, when would be a final draft of cores to be rotated be published, etc. questions would be answered with _patience_ and input from other cores. We would have a plan in K so, that WOULD be a step forward as discussed in the beginning and be implemented in L, ensuring out empathetic stand. The essence of the matter is: We need to change the dynamics slowly and with patience for maintaining a good balance. Best, -Nikhil From: Kuvaja, Erno kuv...@hp.com Sent: Tuesday, March 3, 2015 9:48 AM To: OpenStack Development Mailing List (not for usage questions); Daniel P. Berrange Cc: krag...@gmail.com Subject: Re: [openstack-dev] [Glance] Core nominations. Nikhil, If I recall correctly this matter was discussed last time at the start of the L-cycle and at that time we agreed to see if there is change of pattern to later of the cycle. There has not been one and I do not see reason to postpone this again, just for the courtesy of it in the hopes some of our older cores happens to make review or two. I think Flavio’s proposal combined with the new members would be the right way to reinforce to momentum we’ve gained in Glance over past few months. I think it’s also the right message to send out for the new cores (including you and myself ;) ) that activity is the key to maintain such status. - Erno From: Nikhil Komawar [mailto:nikhil.koma...@rackspace.com] Sent: 03 March 2015 04:47 To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage questions) Cc: krag...@gmail.com Subject: Re: [openstack-dev] [Glance] Core nominations. Hi all, After having thoroughly thought about the proposed rotation and evaluating the pros and cons of the same at this point of time, I would like to make an alternate proposal. New Proposal: 1. We should go ahead with adding more core members now. 2. Come up with a plan and give additional notice for the rotation. Get it implemented one month into Liberty. Reasoning: Traditionally, Glance program did not implement rotation. This was probably with good reason as the program was small and the developers were working closely together and were aware of each others' daily activities. If we go ahead with this rotation it would be implemented for the first time and would appear to have happened out-of-the-blue. It would be good for us to make a modest attempt at maintaining the friendly nature of the Glance development team, give them additional notice and preferably send them a common email informing the same. We should propose at least a tentative plan for rotation so that all the other core members are aware of their responsibilities. This brings to my questions, is the poposed list for rotation comprehensive? What is the basis for missing out some of them? What would be a fair policy or some level of determinism in expectations? I believe that we should have input from the general Glance community (and the OpenStack community too) for the same. In order for all this to be sorted out, I kindly request
Re: [openstack-dev] [Glance] Core nominations.
So I’m +1 on giving these cores notice and perhaps voting on their removal separately (as was recently done in another project or two). Perhaps the way to compromise here would be to submit a change to the relevant documentation in Glance outlining when a core can be removed (or when the proposal to remove them can be made) including the fact that existing cores are not exempt. Detailing the process will be good for everyone, existing active cores, existing inactive cores, and new cores (like myself). It will also give us the ability to say to a new core “please keep these guidelines in mind and understand that if your priorities change, we will remove you (without malice) to keep the core list concise and to keep momentum at the desired level.” I have no issue discussing this proposal and having it land for Liberty. I also do not see a reason why we shouldn’t reach out to those existing inactive cores to explain to them the situation and ask them if they would rather remove themselves before we vote to have them removed. I don’t think any of them will disagree that they haven’t done the work necessary to maintain core-status during Kilo. To answer Nikhil’s questions: I think Flavio picked out a handful of people as an example. I doubt he deliberately skipped over some for any reason other than wishing to reply quickly. Is there a list of people that have done little to no reviews and submitted few if not any changes during Kilo that are currently cores? If so, we should be answering the following: - Who are they? - How many of them are there? - If they’re already inactive, how would removing them hurt forward progress in Glance? - Has anyone reached out to them individually? I agree we should move forward in a way that will not alienate people, and in a way that not only appears fair to everyone else, but is fair. I would hope none of these people would take remove personally since Glance’s continued momentum and progress is not a personal reflection on any of them (it should only reflect those who are actively participating in the project). On 3/3/15, 10:10, Nikhil Komawar nikhil.koma...@rackspace.com wrote: If it was not clear in my previous message, I would like to again emphasize that I truly appreciate the vigor and intent behind Flavio's proposal. We need to be proactive and keep making the community better in such regards. However, at the same time we need to act fairly, with patience and have a friendly strategy for doing the same (thus maintaining a good balance in our progress). I should probably respond to another thread on ML mentioning my opinion that the community's success depends on trust and empathy and everyone's intent as well as effort in maintaining these principles. Without them, it will not take very long to make the situation chaotic. The questions I poised are still unanswered: There are a few members who have been relatively inactive this cycle in terms of reviews and have been missed in Flavio's list (That list is not comprehensive). On what basis have some of them been missed out and if we do not have strong reason, are we being fair? Again, I would like to emphasize that, cleaning of the list in such proportions at this point of time does NOT look OK strategy to me. To answer your concerns: (Why was this not proposed earlier in the cycle?) There are multiple reasons which are hard to be put in words because they are subtle and guided the momentum at that point of time. I agree that this was indeed proposed in the beginning of K cycle however, with less enthusiasm from all the members. Only a select few were insistent and democratically, it got deprioritized. There were other major concerns to be handled like position of the community members on some of the newer features. That in turn would have guided, the commitment from some of the members to the Glance program (probably based on their other priorities). Hence, I think coming with a good plan during the feature freeze period including when and how are we going to implement it, when would be a final draft of cores to be rotated be published, etc. questions would be answered with _patience_ and input from other cores. We would have a plan in K so, that WOULD be a step forward as discussed in the beginning and be implemented in L, ensuring out empathetic stand. The essence of the matter is: We need to change the dynamics slowly and with patience for maintaining a good balance. Best, -Nikhil From: Kuvaja, Erno kuv...@hp.com Sent: Tuesday, March 3, 2015 9:48 AM To: OpenStack Development Mailing List (not for usage questions); Daniel P. Berrange Cc: krag...@gmail.com Subject: Re: [openstack-dev] [Glance] Core nominations. Nikhil, If I recall correctly this matter was discussed last time at the start of the L-cycle and at that time we agreed to see if there is change of pattern to later of the cycle. There has not been one and I do not see reason
Re: [openstack-dev] [Glance] Core nominations.
Nikhil, If I recall correctly this matter was discussed last time at the start of the L-cycle and at that time we agreed to see if there is change of pattern to later of the cycle. There has not been one and I do not see reason to postpone this again, just for the courtesy of it in the hopes some of our older cores happens to make review or two. I think Flavio's proposal combined with the new members would be the right way to reinforce to momentum we've gained in Glance over past few months. I think it's also the right message to send out for the new cores (including you and myself ;) ) that activity is the key to maintain such status. - Erno From: Nikhil Komawar [mailto:nikhil.koma...@rackspace.com] Sent: 03 March 2015 04:47 To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage questions) Cc: krag...@gmail.com Subject: Re: [openstack-dev] [Glance] Core nominations. Hi all, After having thoroughly thought about the proposed rotation and evaluating the pros and cons of the same at this point of time, I would like to make an alternate proposal. New Proposal: 1. We should go ahead with adding more core members now. 2. Come up with a plan and give additional notice for the rotation. Get it implemented one month into Liberty. Reasoning: Traditionally, Glance program did not implement rotation. This was probably with good reason as the program was small and the developers were working closely together and were aware of each others' daily activities. If we go ahead with this rotation it would be implemented for the first time and would appear to have happened out-of-the-blue. It would be good for us to make a modest attempt at maintaining the friendly nature of the Glance development team, give them additional notice and preferably send them a common email informing the same. We should propose at least a tentative plan for rotation so that all the other core members are aware of their responsibilities. This brings to my questions, is the poposed list for rotation comprehensive? What is the basis for missing out some of them? What would be a fair policy or some level of determinism in expectations? I believe that we should have input from the general Glance community (and the OpenStack community too) for the same. In order for all this to be sorted out, I kindly request all the members to wait until after the k3 freeze, preferably until a time at which people would have a bit more time in their hand to look at their mailboxes for unexpected proposals of rotation. Once a decent proposal is set, we can announce the change-in-dynamics of the Glance program and get everyone interested familiar with it during the summit. Whereas, we should not block the currently active to-be-core members from doing great work. Hence, we should go ahead with adding them to the list. I hope that made sense. If you've specific concerns, I'm free to chat on IRC as well. (otherwise) Thoughts? Cheers, -Nikhil From: Alexander Tivelkov ativel...@mirantis.commailto:ativel...@mirantis.com Sent: Tuesday, February 24, 2015 7:26 AM To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage questions) Cc: krag...@gmail.commailto:krag...@gmail.com Subject: Re: [openstack-dev] [Glance] Core nominations. +1 on both proposals: rotation is definitely a step in right direction. -- Regards, Alexander Tivelkov On Tue, Feb 24, 2015 at 1:19 PM, Daniel P. Berrange berra...@redhat.commailto:berra...@redhat.com wrote: On Tue, Feb 24, 2015 at 10:47:18AM +0100, Flavio Percoco wrote: On 24/02/15 08:57 +0100, Flavio Percoco wrote: On 24/02/15 04:38 +, Nikhil Komawar wrote: Hi all, I would like to propose the following members to become part of the Glance core team: Ian Cordasco Louis Taylor Mike Fedosin Hemanth Makkapati Please, yes! Actually - I hope this doesn't come out harsh - I'd really like to stop adding new cores until we clean up our current glance-core list. This has *nothing* to do with the 4 proposals mentioned above, they ALL have been doing an AMAZING work. However, I really think we need to start cleaning up our core's list and this sounds like a good chance to make these changes. I'd like to propose the removal of the following people from Glance core: - Brian Lamar - Brian Waldon - Mark Washenberger - Arnaud Legendre - Iccha Sethi - Eoghan Glynn - Dan Prince - John Bresnahan None of the folks in the above list have neither provided reviews nor have they participated in Glance discussions, meetings or summit sessions. These are just signs that their focus have changed. While I appreciate their huge efforts in the past, I think it's time for us to move forward. It goes without saying that all of the folks above are more than welcome to join the glance-core team again if their focus goes back to Glance. Yep, rotating out inactive members
Re: [openstack-dev] [Glance] Core nominations.
Hi all, After having thoroughly thought about the proposed rotation and evaluating the pros and cons of the same at this point of time, I would like to make an alternate proposal. New Proposal: 1. We should go ahead with adding more core members now. 2. Come up with a plan and give additional notice for the rotation. Get it implemented one month into Liberty. Reasoning: Traditionally, Glance program did not implement rotation. This was probably with good reason as the program was small and the developers were working closely together and were aware of each others' daily activities. If we go ahead with this rotation it would be implemented for the first time and would appear to have happened out-of-the-blue. It would be good for us to make a modest attempt at maintaining the friendly nature of the Glance development team, give them additional notice and preferably send them a common email informing the same. We should propose at least a tentative plan for rotation so that all the other core members are aware of their responsibilities. This brings to my questions, is the poposed list for rotation comprehensive? What is the basis for missing out some of them? What would be a fair policy or some level of determinism in expectations? I believe that we should have input from the general Glance community (and the OpenStack community too) for the same. In order for all this to be sorted out, I kindly request all the members to wait until after the k3 freeze, preferably until a time at which people would have a bit more time in their hand to look at their mailboxes for unexpected proposals of rotation. Once a decent proposal is set, we can announce the change-in-dynamics of the Glance program and get everyone interested familiar with it during the summit. Whereas, we should not block the currently active to-be-core members from doing great work. Hence, we should go ahead with adding them to the list. I hope that made sense. If you've specific concerns, I'm free to chat on IRC as well. (otherwise) Thoughts? Cheers, -Nikhil From: Alexander Tivelkov ativel...@mirantis.com Sent: Tuesday, February 24, 2015 7:26 AM To: Daniel P. Berrange; OpenStack Development Mailing List (not for usage questions) Cc: krag...@gmail.com Subject: Re: [openstack-dev] [Glance] Core nominations. +1 on both proposals: rotation is definitely a step in right direction. -- Regards, Alexander Tivelkov On Tue, Feb 24, 2015 at 1:19 PM, Daniel P. Berrange berra...@redhat.commailto:berra...@redhat.com wrote: On Tue, Feb 24, 2015 at 10:47:18AM +0100, Flavio Percoco wrote: On 24/02/15 08:57 +0100, Flavio Percoco wrote: On 24/02/15 04:38 +, Nikhil Komawar wrote: Hi all, I would like to propose the following members to become part of the Glance core team: Ian Cordasco Louis Taylor Mike Fedosin Hemanth Makkapati Please, yes! Actually - I hope this doesn't come out harsh - I'd really like to stop adding new cores until we clean up our current glance-core list. This has *nothing* to do with the 4 proposals mentioned above, they ALL have been doing an AMAZING work. However, I really think we need to start cleaning up our core's list and this sounds like a good chance to make these changes. I'd like to propose the removal of the following people from Glance core: - Brian Lamar - Brian Waldon - Mark Washenberger - Arnaud Legendre - Iccha Sethi - Eoghan Glynn - Dan Prince - John Bresnahan None of the folks in the above list have neither provided reviews nor have they participated in Glance discussions, meetings or summit sessions. These are just signs that their focus have changed. While I appreciate their huge efforts in the past, I think it's time for us to move forward. It goes without saying that all of the folks above are more than welcome to join the glance-core team again if their focus goes back to Glance. Yep, rotating out inactive members is an important step to ensure that the community has clear view of who the current active leadership is. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org
