[openstack-dev] [all][infra][tc][ptl] Scaling up code review process (subdir cores)
john at johngarbutt.com
Wed Jun 3 16:57:03 UTC 2015
+1 to ttx and Jame's points on trust and relationships, indeed
referencing the summit session that ttx mentioned:
On 3 June 2015 at 16:01, Nikola Đipanov <ndipanov at redhat.com> wrote:
> On 06/03/2015 02:43 PM, Boris Pavlovic wrote:
>> I don't believe even my self, because I am human and I make mistakes.
>> My goal on the PTL position is to make such process that stops "human"
>> mistakes before they land in master. In other words everything should be
>> automated and pre not post checked.
> I used to believe exactly this some time ago - but I don't anymore. Lack
> of bugs is not what makes good software (tho you don't want too many of
> them :) ).
> Focusing on bugs and automation to avoid them is misguided
Before we did this, most times I pulled master, I was unable to boot a
VM. Its nice we fixed that.
History has proven that anything we don't test gets broken very quickly.
But this is
>, and so is
> the idea that code review is there to spot bugs before they land in
> tree. Code reviewers should make sure that the abstractions are solid,
> the code is modular, readable and maintainable - exactly the stuff
> machines (still?) can't do (*).
So the great thing about the tests we have, is it does help you
concentrate more on the important bits humans are good at.
pep8 and hacking check lots of things I no longer have to, and I am
very happy about that.
> This was one of the arguments against doing exactly what you propose in
> Nova - we want the same (high?) level of reviews in all parts of the
> code, and strong familiarity with the whole.
> But I think it's failing - Nova is just too big - and there is not
> enough skilled people to do the work without a massive scope reduction.
> I am not sure how to fix it TBH (tho my gut feeling says we should
> loosen not tighten the constraints).
So we did have a session on this a the summit:
I am yet to properly write that up. We don't have a solution, but we
do now have a plan to try and improve things, and it looks something
like this, in no particular order...
Step A is having better developer documentation around the reasons
behind the big strokes of our architecture. This tribal knowledge is
hard to get, and frankly I don't think a single person currently has
the full context here. I am looking for a better something, rather
than an out of date nothing. Perfection here is costly and largely
Step B is having better / more explicit mentoring for new
contributors, and helping them get started. This includes both
reviewers and those submitting code / features. This effort will help
us improve the artefacts generated by Step 1, so its more useful for
folks gaining context. This used to happen all the time, I feel we got
out of the habit.
Step C do a better job of describing WHY we do what we are doing.
Firstly so people know why we do what appear to be crazy things. For
example, Nova might be there first experience of OpenStack, or any
sort of open source development. Secondly, so we can have better
informed conversations about how to improve how we work.
Step D allow self organising sub-teams are now free to decide on top
few patches that are considered "ready to merge" by that subteam and
thus overdue in terms of "ready for nova-core review". Thats happening
in this etherpad:
Increased nova-core focus (as seen during feature freeze) tends to
help things get through the system quickly. Over time, its possible a
subteam might gain enough trust, that we treat their recommendation as
a +2. But we did agree to leave that on the back burner for liberty-1
and see how things progress throughout the liberty release. Its hopped
the addition of tagging in Gerrit might eventually remove the need for
Step E continue to halt Nova scope creep, and ideally reduce the
scope. The first part is by starting to record what the "tribal
knowledge" says the scope is:
The second part is better seams and contracts between the different
components in Nova. One of the aims of that being that it will be
easier for different groups to work more independently. Much of the
scheduler work is looking to create a more stable interface so its
possible the scheduler (and maybe resource tracker) can gain more
autonomy. The cells v2 work is helping evolve the API <-> compute
interface. The tasks work is likely to help a major evolution of the
virt driver interface. The virt driver interface is also being
improved by the objects work, including formalising image properties
and flavor extra specs. While it may never be practical for any or all
of these things to move out of Nova git tree, looser coupling through
some stricter contracts will help.
Step F review the impact the above ideas are having, and decide where
we go next.
More information about the OpenStack-dev