[openstack-dev] [Glance] Core nominations.

Nikhil Komawar nikhil.komawar at RACKSPACE.COM
Sun Mar 8 18:40:56 UTC 2015

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.


From: Gary Kotton <gkotton at 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" <flavio at redhat.com> wrote:

>On 07/03/15 23:16 +0000, 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
>>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
>>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
>>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
>>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

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.
>>Hope that answered your questions, at least for the time being!
>>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
>>core-reviewers? For instance, with core-reviewers it is very clear that
>>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
>>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
>>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,
>>Mike, Ian: It's a good idea to have the policy however, we need to craft
>>that is custom to the Glance program. It will be a bit different to ones
>>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
>>for metadefs.
>>While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are
>>it also makes me wonder if that's going to help us in long term. If not,
>>what can we do now to set a good path forward?
>>Flavio, Erno, Malini, Louis, Mike: Drafting a guideline policy and
>>rotation based on that was my intent so that everyone is aware of the
>>in the program. That would let the core reviewers know what their duties
>>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
>>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
>>can affect project decisions hence, this change may be important. This
>>may involve some interactions with governance so, will take more time.
>>Malini: I wish to take a strategic decision here rather an agile one.
>>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
>>Kilo). They can be added back to the list faster in the future if they
>>contributing to Glance again.
>>The criterion is:
>>Reviews <= 50 in combined cycles.
>>Proposal to remove the following members(review_count) from the
>>  · 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
>>inactive. Thus, misses out on a few names due to lack of established
>>We can do more about rotation in the following weeks.
>>Hope it works!
>>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>
>>    I like that idea. Can you start it out with Nova or Neutron’s
>>FYI, the core reviewer guidelines for Neutron are in-tree now [1], along
>>all of our other policies around operating in Neutron [2].
>>    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
>>    >Glance Review Guidelines
>>    >
>>    >JabsI/edit?usp=sharing
>>>MfkKVxiUz_D5z1UTOK90rBJOmTEuKv2QJcU&e= >    >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>:
>>    >
>>    >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
>>    >> 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
>>    >> 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
>>    >
>>    >/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://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
>>OpenStack Development Mailing List (not for usage questions)
>>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>Flavio Percoco

OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe

More information about the OpenStack-dev mailing list