Open Stack

On 06/03/15 21:09 +0000, Ian Cordasco wrote:
>
>
>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.

+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 <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
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

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