Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule

[hasufell]

On 07/05/2015 08:05 AM, Andrew Savchenko wrote:
> On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote:
>> It's important that the review flow is well-understood and efficient.
>
> This is impossible in our case due to the lack of manpower.
> We already have a lot of bugs, patches, stabilization requests
> hanging over there for months and even years. Stabilization request
> will require at least two developers to participate in each commit.
> This will double manpower required at least. Such approach can kill
> the whole project.
>

People misinterpret "manpower". If we successfully switch to a
code-review approach, then we will need _less_ manpower in the sense of
actual gentoo developers.

However, this does not and cannot happen over night since it requires a
shift of thinking and a change of culture, involving the whole community.

But if we just want to add more independent committers to the core
gentoo tree, then we are definitely making quality worse.

I'm not particularly sure that an alternative review-based workflow can
work here, given that our workflow has been broken for quite a few
years. Such things become a strong habit and may leave some of our
developers in confusion.

But it could start (and already has, afaik) with project-internal
requirements (e.g. kde project demanding reviews). When the different
projects increase workflow strictness, it will increase overall
strictness as well.

> Code review is good at a limited scope, e.g. for non-developers
> where we have review anyway.
>

This is not enough to maintain high quality. I've seen some ebuilds in
user overlays which have higher quality than their gx86 counterpart.


However, that said... I don't think it currently makes sense to enforce
a strict global review workflow. However, we should encourage
gentoo-internal projects to become more strict (and e.g. only have one
or two "pushers").