On 06/03/15 21:09 +0000, Ian Cordasco wrote:


On 3/6/15, 15:04, "Nikhil Komawar" <nikhil.koma...@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 <mest...@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.corda...@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" <mfedo...@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
<ihrac...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>


<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
@flaper87
Flavio Percoco

Attachment: pgp8zLSt5GCB2.pgp
Description: PGP signature

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to