Open Stack

On 3/6/15, 15:04, "Nikhil Komawar" <nikhil.komawar at 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 <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> 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" <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_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
>><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
>
>
>
>
>
>
>
>
>
>