Gentoo Archives: gentoo-dev

From: Rich Freeman <rich0@g.o>
To: gentoo-dev <gentoo-dev@l.g.o>
Subject: Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule
Date: Thu, 09 Jul 2015 12:56:08
Message-Id: CAGfcS_myksmH94zixEKAcqyBPFj-02OHymGap3WbZWy-Rrobnw@mail.gmail.com
In Reply to: Re: Code Review Systems Was: [gentoo-dev] Git Migration: launch plan & schedule by Peter Stuge
1 On Thu, Jul 9, 2015 at 8:25 AM, Peter Stuge <peter@×××××.se> wrote:
2 > Rich Freeman wrote:
3 >> I suspect that trying to force it would basically end up putting
4 >> the entire distro on hold until most of the current devs quit,
5 >
6 > I think you're right. I also think those developers should quit right
7 > here and now. I don't think they will.
8 >
9
10 The thing is that if a bunch of devs want to create a review-only
11 Gentoo fork they can just do it. The result would be about the same.
12 Trying to force it on Gentoo would just result in most of the Gentoo
13 devs changing the name and proceeding basically as it is, and Gentoo
14 would just become another XFree86.
15
16 The way you change an FOSS project is to influence the current
17 contributions, or to make contributions of your own. Trying to order
18 people around doesn't really change anything in the end.
19
20 Hence my suggestion to try something like this out in a project where
21 there is interest. Build from success, and win people over. In the
22 end the "hard" power of a body like the Council is just the power to
23 halt progress, not create it. That power should be focused on
24 situations where the "progress" is self-destructive. Obviously a body
25 like the Council also has "soft" powers like leadership/etc, but that
26 really isn't enough to just order change by fiat. Plus, we're all
27 elected for our ability to generally represent the will of the
28 developer community, so you shouldn't be too surprised when we don't
29 try to push policies that most devs disagree with.
30
31 In any case, to some extent the review workflow already exists on the
32 proxy maintainer project. There is no limit to the number of packages
33 they can maintain, or the number of reviewers they can have.
34
35 --
36 Rich