<div dir="ltr">Hi Mike, thanks, now it's clear.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 3, 2015 at 9:19 AM, Mike Scherbakov <span dir="ltr"><<a href="mailto:mscherbakov@mirantis.com" target="_blank">mscherbakov@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">







<p><span>Thank you all for the feedback.</span></p>
<p><span></span><br></p>
<p><span>Dims -</span></p><span class="">
<p><span>> 1) I'd advise to codify a proposal in fuel-specs under a 'policy' directory</span></p>
</span><p><span>I think it's great idea and I'll do it.</span></p><span class="">
<p><span></span><br></p>
<p><span>> 2) We don't have SME terminology, but we do have Maintainers both in oslo-incubator</span></p>
</span><p><span>I like "Maintainers" more than SMEs, thank you for suggestion. I'd switch SME -> Maintainer everywhere.</span></p><span class="">
<p><span></span><br></p>
<p><span>> 3) Is there a plan to split existing repos to more repos? Then each repo can have a core team (one core team for one repo), PTL takes care of all repos and MAINTAINERS take care of directories within a repo. That will line up well with what we are doing elsewhere in the community (essentially "Component Lead" is a core team which may not be a single person).</span></p>
</span><p><span>That's the plan, with one difference though. According to you, there is a core team per repo without a lead identified. In my proposal, I'd like to ensure that we always choose a lead by the process of voting. I'd like to have voting process of identifying a component lead. It has to be fair process.</span></p><span class="">
<p><span></span><br></p>
<p><span>> We do not have a concept of SLA anywhere that i know of, so it will have to be some kind of social consensus and not a real carrot/stick.</span></p>
</span><p><span>> As for me the idea of SLA contradicts to qualitative reviews.</span></p>
<p><span>I'm not thinking about carrot or stick here. I'd like to ensure that core reviewers and component leads are targeted to complete reviews within a certain time. If it doesn't happen, then patchset needs to be discussed during IRC meeting if we can delegate some testing, etc. to someone. If there are many patchsets out of SLA, then we'd consider other changes (decide to drop something from the release so to free up resources or something else).</span></p>
<p><span>We had a problem in the past, when we would not pay attention to a patch proposed by someone before it's being escalated. I'm suggesting a solution for that problem. SLA is the contract between contributor and reviewer, and both would have same expectations on how long would it take to review the patch. Without expectations aligned, contributors can get upset easily. They may expect that their code will be reviewed and merged within hours, while it fact it's days. I'm not even talking about patches which can be forgotten and hang in the queue for months...</span></p><span class="">
<p><span></span><br></p>
<p><span>> If we succeed in reducing the load on core reviewers, it will mean that core reviewers will do less code reviews. This could lead to core reviewer demotion.</span></p>
</span><p><span>I expect that there will be a drop in code reviews being done by core reviewers team. This is the point actually - do less reviews, but do it more thoroughly. Don't work on patches which have easy mistakes, as those should be cought by maintainers, before these patches come to the core reviewer's plate. I don't think though that it will lead to core reviewer "demotion". Still, you will be doing many reviews - just less than before, and other who did a little - will do more reviews, potentially becoming joining a core team later.</span></p><span class="">
<p><span></span><br></p>
<p><span>> It would be nice if Jenkins could add reviewers after CI +1, or we can use gerrit dashboard for SMEs to not waste their time on review that has not yet passed CI and does not have +1 from other reviewers.</span></p>
</span><p><span>This is good suggestion. I agree.</span></p><span class="">
<p><span></span><br></p>
<p><span>> AFAIK Boris Pavlovic introduced some scripts</span></p>
<p><span>> in Rally which do basic preliminary check of review message, checking</span></p>
<p><span>> that it's formally correct.</span></p>
</span><p><span>Thanks Igor, I believe this can be applied as well.</span></p><span class="">
<p><span></span><br></p>
<p><span>> Another thing is I got a bit confused by the difference between Core Reviewer and Component Lead,</span></p>
<p><span>> aren't those the same persons? Shouldn't every Core Reviewer know the architecture, best practises</span></p>
<p><span>> and participate in design architecture sessions?</span></p>
</span><p><span>Component Lead is being elected by core reviewers team as the lead. So it's just another core reviewer / architect, but with the right to have a final word. Also, for large parts like fuel-library / nailgun, I'd expect this person to be free from any feature-work. For smaller things, like network verifier, I don't think that we'd need to have dedicated component owner who will be free from any feature work.</span></p>
<p><span></span><br></p>
<p><span>Igor K., Evgeny L, did I address your questions regarding SLA and component lead vs core reviewer?</span></p><p><span>Thank you,</span></p></div><div class="HOEnZb"><div class="h5"><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 2, 2015 at 9:28 AM Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 09/02/2015 08:45 AM, Igor Kalnitsky wrote:<br>
>> I think there's plenty of examples of people in OpenStack projects<br>
>> that both submit code (and lead features) that also do code review<br>
>> on a daily basis.<br>
><br>
> * Do these features huge?<br>
<br>
Yes.<br>
<br>
> * Is their code contribution huge or just small patches?<br>
<br>
Both.<br>
<br>
> * Did they get to master before FF?<br>
<br>
Yes.<br>
<br>
> * How many intersecting features OpenStack projects have under<br>
> development? (since often merge conflicts requires a lot of re-review)<br>
<br>
I recognize that Fuel, like devstack, has lots of cross-project<br>
dependencies. That just makes things harder to handle for Fuel, but it's<br>
not a reason to have core reviewers not working on code or non-core<br>
reviewers not doing reviews.<br>
<br>
> * How often OpenStack people are busy on other activities, such as<br>
> helping fellas, troubleshooting customers, participate design meetings<br>
> and so on?<br>
<br>
Quite often. I'm personally on IRC participating in design discussions,<br>
code reviews, and helping people every day. Not troubleshooting<br>
customers, though...<br>
<br>
> If so, do you sure they are humans then? :) I can only speak for<br>
> myself, and that's what I want to say: during 7.0 dev cycle I burned<br>
> in hell and I don't want to continue that way.<br>
<br>
I think you mean you "burned out" :) But, yes, I hear you. I understand<br>
the pressure that you are under, and I sympathize with you. I just feel<br>
that the situation is not an either/or situation, and encouraging some<br>
folks to only do reviews and not participate in coding/feature<br>
development is a dangerous thing.<br>
<br>
Best,<br>
-jay<br>
<br>
> Thanks,<br>
> Igor<br>
><br>
> On Wed, Sep 2, 2015 at 3:14 PM, Jay Pipes <<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>> wrote:<br>
>> On 09/02/2015 03:00 AM, Igor Kalnitsky wrote:<br>
>>><br>
>>> It won't work that way. You either busy on writing code / leading<br>
>>> feature or doing review. It couldn't be combined effectively. Any<br>
>>> context switch between activities requires an extra time to focus on.<br>
>><br>
>><br>
>> I don't agree with the above, Igor. I think there's plenty of examples of<br>
>> people in OpenStack projects that both submit code (and lead features) that<br>
>> also do code review on a daily basis.<br>
>><br>
>> Best,<br>
>> -jay<br>
>><br>
>><br>
>> __________________________________________________________________________<br>
>> OpenStack Development Mailing List (not for usage questions)<br>
>> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
> __________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div><span class="HOEnZb"><font color="#888888"><div dir="ltr">-- <br></div><div dir="ltr">Mike Scherbakov<br>#mihgen</div>
</font></span><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>