On 3/6/15, 15:04, "Nikhil Komawar" <[email protected]> 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 <[email protected]> >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 ><[email protected]> 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" <[email protected]> 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 >><[email protected]>: >> >>-----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: >>[email protected]?subject:unsubscribe >><http://[email protected]?subject:unsubscribe> > > >><http://[email protected]?subject:unsubscribe> >>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> >> >> >> >> > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: >[email protected]?subject:unsubscribe ><http://[email protected]?subject:unsubscribe> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > > > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
