[openstack-dev] [Glance] Core nominations.
Gary Kotton
gkotton at vmware.com
Sun Mar 8 15:45:59 UTC 2015
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
>>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.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>
>>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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack
>>_neutron_blob_master_doc_source_policies_&d=AwIFaQ&c=Sqcl0Ez6M0X8aeM67LKI
>>iDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=Q
>>mQYMELbTDPVi2GwQ4VXQUrISU26zvqZ3HF7sRakbAM&s=nhf5jHMT2--d5SOm5pQD8ME3ATSG
>>XhALfj7GHkwzieE&e=
>>core-reviewers.rst
>>[2]
>>https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack
>>_neutron_tree_master_doc_source_policies&d=AwIFaQ&c=Sqcl0Ez6M0X8aeM67LKIi
>>DJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=Qm
>>QYMELbTDPVi2GwQ4VXQUrISU26zvqZ3HF7sRakbAM&s=KtneG6roTtYIAIEe2a2uv9pYoq5p2
>>n9kbGiLuPIiBZc&e=
>>
>>
>> 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://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_doc
>>>ument_d_1Iia0BjQoXvry9XSbf30DRwQt-2D-2DODglw-2DZTT-5F5R&d=AwIFaQ&c=Sqcl0
>>>Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3
>>>-diTlNj4GyNc&m=QmQYMELbTDPVi2GwQ4VXQUrISU26zvqZ3HF7sRakbAM&s=qkoKPqPJoCI
>>>x2FMp-Af4TJW2TA2Jj_OcULHtRCnsLO4&e=
>> >JabsI/edit?usp=sharing
>>
>>><https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_do
>>>cument_d_1Iia0BjQoXvry9XSbf30DRwQt-2D-2DODglw-2DZTT-5F5-0A&d=AwIFaQ&c=Sq
>>>cl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq
>>>9N3-diTlNj4GyNc&m=QmQYMELbTDPVi2GwQ4VXQUrISU26zvqZ3HF7sRakbAM&s=n-whXxsc
>>>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>:
>> >
>> >-----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://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)
>>Unsubscribe:
>>OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>--
>@flaper87
>Flavio Percoco
More information about the OpenStack-dev
mailing list