Open Stack

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.makkapati at 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.komawar at 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 <mestery at 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.cordasco at rackspace.com<mailto:ian.cordasco at 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" <mfedosin at mirantis.com<mailto:mfedosin at 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
><ihrachys at redhat.com<mailto:ihrachys at 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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
><http://OpenStack-dev-request@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-request at lists.openstack.org?subject:unsubscribe<http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150307/0a6bdef5/attachment.html>