Open Stack

Joe Gordon wrote:
> [...]
> This sounds like a very myopic solution to the issue you originally
> raised, and I don't think it will solve the underlying issues.
> 
> Taking a step back, you originally raised a concern about how we
> prioritize reviews with the havana-rc-potential tag.
> [...]

I'm with Joe here. Additionally, I don't see how the proposed solution
would solve anything for the original issue.

You propose letting a subteam approve incremental patches in a specific
branch, and propose a big blob every milestone to merge in Nova proper,
so that the result can be considered golden and maintained by the Nova
team. So nova-core would still have to review it, since they put their
name on it. I don't see how reviewing the big blob is a lot easier than
reviewing incremental patches. Doing it under the time pressure of the
upcoming milestone won't drive better results.

Furthermore, the issue you raised was with havana release candidates,
for which we'd definitely not take the "big blob" approach anyway, and
go incremental all the way.


The subsystem mechanism works for the Linux kernel due to a trust model.
Linus doesn't review all patches coming from a subsystem maintainer, he
developed a trust in the work coming from that person over the years.

The equivalent in the OpenStack world would be to demonstrate that you
understand enough of the rest of the Nova code to avoid breaking it (and
to follow new conventions and features added there). This is done by
participating to reviews on the rest of the code. Then your +1s can be
considered as +2s, since you're the domain expert and you are trusted to
know enough of the rest of the code. That model works quite well with
oslo-incubator, without needing a separate branch for every incubated API.

Finally, the best way to not run into those priority hurdles is by
anticipating them. Since hyper-V is not tested at the gate, reviewers
will always be more reluctant in accepting late features and RC fixes
that affect hyper-V code. Landing features at the beginning of a cycle
and working on bugfixes well before we enter the release candidate
phases... that's the best way to make sure your work gets in before release.

Regards,

-- 
Thierry Carrez (ttx)