Hi Mike, thanks, now it's clear.
On Thu, Sep 3, 2015 at 9:19 AM, Mike Scherbakov
wrote:
> Thank you all for the feedback.
>
>
> Dims -
>
> > 1) I'd advise to codify a proposal in fuel-specs under a 'policy'
> directory
>
> I think it's great idea and I'll do it.
>
>
> > 2) We don't have SME term
Thank you all for the feedback.
Dims -
> 1) I'd advise to codify a proposal in fuel-specs under a 'policy'
directory
I think it's great idea and I'll do it.
> 2) We don't have SME terminology, but we do have Maintainers both in
oslo-incubator
I like "Maintainers" more than SMEs, thank you fo
On 09/02/2015 08:45 AM, Igor Kalnitsky wrote:
I think there's plenty of examples of people in OpenStack projects
that both submit code (and lead features) that also do code review
on a daily basis.
* Do these features huge?
Yes.
* Is their code contribution huge or just small patches?
Bot
> I think there's plenty of examples of people in OpenStack projects
> that both submit code (and lead features) that also do code review
> on a daily basis.
* Do these features huge?
* Is their code contribution huge or just small patches?
* Did they get to master before FF?
* How many intersecti
On 09/02/2015 03:00 AM, Igor Kalnitsky wrote:
It won't work that way. You either busy on writing code / leading
feature or doing review. It couldn't be combined effectively. Any
context switch between activities requires an extra time to focus on.
I don't agree with the above, Igor. I think the
It won't work that way. You either busy on writing code / leading
feature or doing review. It couldn't be combined effectively. Any
context switch between activities requires an extra time to focus on.
On Wed, Sep 2, 2015 at 5:46 AM, Tomasz Napierala
wrote:
>> On 01 Sep 2015, at 03:43, Igor Kalni
> On 01 Sep 2015, at 03:43, Igor Kalnitsky wrote:
>
> Hi folks,
>
> So basically..
>
> * core reviewers won't be feature leads anymore
> * core reviewers won't be assigned to features (or at least not full-time)
> * core reviewers will spend time doing review and participate design meetings
> *
Hi folks,
So basically..
* core reviewers won't be feature leads anymore
* core reviewers won't be assigned to features (or at least not full-time)
* core reviewers will spend time doing review and participate design meetings
* core reviewers will spend time triaging bugs
Is that correct?
Thank
> On 27 Aug 2015, at 07:58, Evgeniy L wrote:
>
> Hi Mike,
>
> I have several comments.
>
> >> SLA should be the driver of doing timely reviews, however we can’t allow
> >> to fast-track code into master suffering quality of review ...
>
> As for me the idea of SLA contradicts to qualitative r
>> - SME reviews the code within SLA, which should be defined per component
Also I would like to add, that I'm not against of metrics, we can collect
metrics, in order to figure out if some improvement in the process helped
to speed up reviews, but asking Cores/SMEs to do the job faster will
defin
Hi Mike,
I have several comments.
>> SLA should be the driver of doing timely reviews, however we can’t allow
to fast-track code into master suffering quality of review ...
As for me the idea of SLA contradicts to qualitative reviews.
Another thing is I got a bit confused by the difference betw
Mike,
speaking of automation, AFAIK Boris Pavlovic introduced some scripts
in Rally which do basic preliminary check of review message, checking
that it's formally correct. It should make life of reviewers a bit
easier, you might want to introduce them in Fuel as well, if not yet.
Regards,
Igor Mar
Hi,
I'm all in for any formalization and automation of review process. The only
concern that I see here is about core reviewers involvement metrics. 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
de
Mike,
This is a great start.
1) I'd advise to codify a proposal in fuel-specs under a 'policy' directory
(obviously as a review in fuel-specs repo) So everyone agrees to the
structure of the teams and terminology etc. Example oslo uses a directory
to write down some of our decisions.
http://git.o
Hi all,
let's discuss code review process in Fuel and what we can improve. For
those who want to just have a quick context of this email, please check out
presentation slides [5].
** Issues **
Depending on a Fuel subproject, I'm aware of two buckets of issues with
code review in Fuel:
a) It is ha
15 matches
Mail list logo
