| 1 |
On Thu, Jul 9, 2015 at 5:31 AM, hasufell <hasufell@g.o> wrote: |
| 2 |
> |
| 3 |
> The quality problem is that we have too many developers. If you make |
| 4 |
> community contributions easier, sane and more reliable (due to code |
| 5 |
> review) then you solve several problems at once, because you need _less_ |
| 6 |
> developers. Are you aware that we could potentially "pull" in hundreds |
| 7 |
> of contributors who chose to work on their personal overlay instead of |
| 8 |
> the gentoo tree? Are you aware that there are a lot of those people? |
| 9 |
|
| 10 |
Yes and no. |
| 11 |
|
| 12 |
I'll agree that with a review workflow we might only need one reviewer |
| 13 |
for every 10 contributors, or something like that. If we have 100 |
| 14 |
active devs today, in theory we could instead turn 20 of them into |
| 15 |
reviewers, and now we can support 2000 contributors. |
| 16 |
|
| 17 |
There are some big assumptions with this kind of argument, though: |
| 18 |
1. We might find that we don't even have 20 devs interested in doing |
| 19 |
a substantial amount of review. |
| 20 |
2. The main repository is very diverse. If 50% of our packages have |
| 21 |
only one person interested in maintaining them, then they get dropped |
| 22 |
since reviewers will ignore their contributions. Or, they'll just |
| 23 |
rubber-stamp them which is adding valueless work. |
| 24 |
|
| 25 |
So, a review system could make manpower either more of an issue or |
| 26 |
less of one. I suspect that trying to force it would basically end up |
| 27 |
putting the entire distro on hold until most of the current devs quit, |
| 28 |
and a new crop signs up who is interested in using the new workflow, |
| 29 |
and then they're starting with zero experience. |
| 30 |
|
| 31 |
I think a review model is best implemented by individual project |
| 32 |
teams. They could use it to track changes in an overlay or branch in |
| 33 |
the main tree, and then move those into the main tree using whatever |
| 34 |
quality system seems best. The team can figure out what is working |
| 35 |
best for it, and if over time a large number of devs feel that it is a |
| 36 |
good way to work we could then talk about doing it with the main tree. |
| 37 |
I still suspect we'll end up having problems with the 70% of packages |
| 38 |
that don't fall into a project though. |
| 39 |
|
| 40 |
-- |
| 41 |
Rich |
Archives