On 2/22/16, 10:13 AM, "Jeff Peeler" <jpee...@redhat.com> wrote:
>On Mon, Feb 22, 2016 at 9:07 AM, Steven Dake (stdake) <std...@cisco.com> >wrote: >> The issue isn't about reviewing patches in my opinion. Obviously people >> shouldn't jam patches through the review queue that they know will be >> counter-productive to the majority view of the core reviewers. If they >>do, >> they can easily be reverted by 3 different core reviewers. Our core >> reviewers are adults and don't behave in this way. I have seen a couple >> patches "jammed through" and not reverted, from multiple companies >>rather >> then just one company and it just made everyone angry. I think folks >>have >> learned from that and tend not to "jan through contentious changes" >>unless >> it is time critical (as in breaking gate, or busted master, or milestone >> deadline). >> >> The issue is around policy setting. The PTL should NOT be a dictator >>and >> set policy on their own whim. The way we set policy in Kolla (and I >>believe >> in other OpenStack projects) is by formal majority vote. For example, >>one >> policy we have set is that we permit third party proprietary distros and >> plugins to interact and even be a part of our Dockerfile.j2 if someone >>steps >> up to maintain them. NB our specs directory are actually policy >>"direction" >> rather then hard policies. That is why spec's require a majority vote >>to >> approve. >> >> Folks that have responded on this thread thus far have seem to missed >>this >> policy point and focused on the reviewing of patches. > >I think the reason people are so focused on reviewing patches is >because that is the "core" job of a core reviewer. I feel like the >Kolla project votes a lot more on policy than other projects (I'm >including IRC and during formal gatherings), so that may be why policy >is not at the forefront of the discussion. > >> All that said, I hear what your saying regarding motivation. The >>original >> discussion was about protecting the project from a lack of diversity in >>the >> core reviewer team which could potentially lead to majority-rules by one >> corporate affiliation on policy matters. What would be an ideal >>outcome in >> my opinion is to keep motivation intact but meet the diversity >>requirements >> set forth in the governance repository to avoid a majority-rules by one >> corporate affiliation situation. There are two ways to do this that I >>can >> think of: >> >> Add core reviewers that aren't quite there yet, but close to meet the >> diversity requirements > >(Label: solution #1) >Perhaps instead of this a specific group such as the drivers team (or >bugs, whatever) can be allowed to vote on policy. This role change >would widen the pool of available candidates while not adding people >prematurely to core status. > >> Or >> Limit core reviewers > >As stated in another thread, this policy wouldn't be acceptable for >some smaller projects with limited diversity. > >> Or >> Another simple solution is to permit a a veto vote from any core >>reviewer >> within the 1 week voting window if a majority (or some other value, >>such as >> 35%) from one corporate affiliation votes yes on a policy decision. >>This >> could be gamed, but at least does not permit policy changes by one >>corporate >> affiliation. With our current core review team, that means 3 people >>could >> vote from RHT (out of the 4 core reviewers) before triggering the veto >>rule. > >(Label: solution #2) >This sounds like to me prevention of "jamming through" which I'm not >sure is necessary, but I do like this option best of those presented >by Steve. Some policies simply aren't that significant, but others >are. I think this is why it's important to bring major policy >decisions to the mailing list. It gives people time to really think >about their opinions/facts and broadens the scope of the discussion. > >> Or >> Permit a veto vote on policy changes (I really don't like this option, >>as it >> gives too much "power" to one individual over the project policy) > >Agreed. > >> I'd like to hear what other core reviewers as well as Kolla developers >>have >> to say about the matter. >> >> As a final note, I am very very (!) anti-process. A project should only >> have as much process as it needs to succeed. Many/most projects(not >> OpenStack, but other projects) go overboard on process. Process just >> creates needless complication, so I am also not hot on setting a bunch >>of >> policies (which require process to execute). The main problem with >>process >> is it creates too many rules for people to make sure they are compliant >> with. This slows the system down, and the system should be fast, >>nimble, >> and agile. >> >> When I open discussion on a policy change, its not like I do it for my >> health - its because I see a serious issue coming down the road. In >>this >> case I don't know precisely how to correct this particular problem, >>which is >> why we are having this discussion. I'd prefer if folks focus on what >>we can >> do to fix it, rather then saying "no lets not do anything". > >Although you mentioned you didn't want the PTL to serve as a dictator, >I think that having the PTL resolve unresolvable disputes is a good >solution to any problems due to lack of diversity. Assuming the first >two labeled solutions didn't work, it's a decent fallback. The PTL has several tools in their toolbox to resolve disputes. Typically I get most of them resolved without a vote. The last tool available to clear logjams is a mailing list vote. I don't want the votes to be meaningless if they are game-able. Regards -steve > >On Mon, Feb 22, 2016 at 9:07 AM, Steven Dake (stdake) <std...@cisco.com> >wrote: >> >> >> From: Eric LEMOINE <elemo...@mirantis.com> >> Reply-To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org> >> Date: Monday, February 22, 2016 at 1:13 AM >> To: "OpenStack Development Mailing List (not for usage questions)" >> <openstack-dev@lists.openstack.org> >> Subject: Re: [openstack-dev] [kolla] discussion about core reviewer >> limitations by company >> >> >> Le 20 févr. 2016 18:12, "Steven Dake (stdake)" <std...@cisco.com> a >>écrit : >>> >>> Hey folks, >>> >>> Mirantis has been developing a big footprint in the core review team, >>>and >>> Red Hat already has a big footprint in the core review team. These >>>are all >>> good things, but I want to avoid in the future a situation in which one >>> company has a majority of core reviewers. Since core reviewers set >>>policy >>> for the project, the project could be harmed if one company has such a >>> majority. This is one reason why project diversity is so important >>>and has >>> its own special snowflake tag in the governance repository. >>> >>> I'd like your thoughts on how to best handle this situation, before I >>> trigger a vote we can all agree on. >>> >>> I was thinking of something simple like: >>> "1 company may not have more then 33% of core reviewers. At the >>> conclusion of PTL elections, the current cycle's 6 months of reviews >>> completed will be used as a metric to select the core reviewers from >>>that >>> particular company if the core review team has shrunk as a result of >>>removal >>> of core reviewers during the cycle." >>> >>> Thoughts, comments, questions, concerns, etc? >> >> >> I think that introducing this policy would not be fair and would even be >> counter-productive. For example, my motivation would be low if I knew I >> couldn't be accepted as a core reviewer because my company already has >>"too >> many" core reviewers. So this policy would close the doors to >>developers >> who could potentially be great contributors to the success of the >>project. >> If anything, a policy where "2 people from the same company should not >> approve a third person from that same company's patch" (as stated by Sam >> Yaple) would sound more acceptable to me. >> >> >> >> Eric, >> >> Life isn't fair :( That said, thank you for your feedback. We >>definitely >> don't want to demotivate people as we balance the core reviewer team >>over >> time. >> >> The issue isn't about reviewing patches in my opinion. Obviously people >> shouldn't jam patches through the review queue that they know will be >> counter-productive to the majority view of the core reviewers. If they >>do, >> they can easily be reverted by 3 different core reviewers. Our core >> reviewers are adults and don't behave in this way. I have seen a couple >> patches "jammed through" and not reverted, from multiple companies >>rather >> then just one company and it just made everyone angry. I think folks >>have >> learned from that and tend not to "jan through contentious changes" >>unless >> it is time critical (as in breaking gate, or busted master, or milestone >> deadline). >> >> The issue is around policy setting. The PTL should NOT be a dictator >>and >> set policy on their own whim. The way we set policy in Kolla (and I >>believe >> in other OpenStack projects) is by formal majority vote. For example, >>one >> policy we have set is that we permit third party proprietary distros and >> plugins to interact and even be a part of our Dockerfile.j2 if someone >>steps >> up to maintain them. NB our specs directory are actually policy >>"direction" >> rather then hard policies. That is why spec's require a majority vote >>to >> approve. >> >> Folks that have responded on this thread thus far have seem to missed >>this >> policy point and focused on the reviewing of patches. >> >> All that said, I hear what your saying regarding motivation. The >>original >> discussion was about protecting the project from a lack of diversity in >>the >> core reviewer team which could potentially lead to majority-rules by one >> corporate affiliation on policy matters. What would be an ideal >>outcome in >> my opinion is to keep motivation intact but meet the diversity >>requirements >> set forth in the governance repository to avoid a majority-rules by one >> corporate affiliation situation. There are two ways to do this that I >>can >> think of: >> >> Add core reviewers that aren't quite there yet, but close to meet the >> diversity requirements >> Or >> Limit core reviewers >> Or >> Another simple solution is to permit a a veto vote from any core >>reviewer >> within the 1 week voting window if a majority (or some other value, >>such as >> 35%) from one corporate affiliation votes yes on a policy decision. >>This >> could be gamed, but at least does not permit policy changes by one >>corporate >> affiliation. With our current core review team, that means 3 people >>could >> vote from RHT (out of the 4 core reviewers) before triggering the veto >>rule. >> Or >> Permit a veto vote on policy changes (I really don't like this option, >>as it >> gives too much "power" to one individual over the project policy) >> >> I'd like to hear what other core reviewers as well as Kolla developers >>have >> to say about the matter. >> >> As a final note, I am very very (!) anti-process. A project should only >> have as much process as it needs to succeed. Many/most projects(not >> OpenStack, but other projects) go overboard on process. Process just >> creates needless complication, so I am also not hot on setting a bunch >>of >> policies (which require process to execute). The main problem with >>process >> is it creates too many rules for people to make sure they are compliant >> with. This slows the system down, and the system should be fast, >>nimble, >> and agile. >> >> When I open discussion on a policy change, its not like I do it for my >> health - its because I see a serious issue coming down the road. In >>this >> case I don't know precisely how to correct this particular problem, >>which is >> why we are having this discussion. I'd prefer if folks focus on what >>we can >> do to fix it, rather then saying "no lets not do anything". >> >> Regards >> -steve >> >> >> >> >>_________________________________________________________________________ >>_ >> 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 >> > >__________________________________________________________________________ >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 __________________________________________________________________________ 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