| 1 |
On 07/09/2015 09:19 AM, Andrew Savchenko wrote: |
| 2 |
> On Mon, 06 Jul 2015 19:20:14 +0200 hasufell wrote: |
| 3 |
>> On 07/05/2015 08:05 AM, Andrew Savchenko wrote: |
| 4 |
>>> On Sat, 4 Jul 2015 20:20:23 +0200 Peter Stuge wrote: |
| 5 |
>>>> It's important that the review flow is well-understood and efficient. |
| 6 |
>>> |
| 7 |
>>> This is impossible in our case due to the lack of manpower. |
| 8 |
>>> We already have a lot of bugs, patches, stabilization requests |
| 9 |
>>> hanging over there for months and even years. Stabilization request |
| 10 |
>>> will require at least two developers to participate in each commit. |
| 11 |
>>> This will double manpower required at least. Such approach can kill |
| 12 |
>>> the whole project. |
| 13 |
>>> |
| 14 |
>> |
| 15 |
>> People misinterpret "manpower". If we successfully switch to a |
| 16 |
>> code-review approach, then we will need _less_ manpower in the sense of |
| 17 |
>> actual gentoo developers. |
| 18 |
> |
| 19 |
> You're mixing different issues here. Code review process for |
| 20 |
> contributors (outside of development team) will indeed save time |
| 21 |
> and manpower. But code review for each developer commit will kill |
| 22 |
> time and effort undoubtedly, while net quality will have little to |
| 23 |
> negligible improvement. |
| 24 |
> |
| 25 |
|
| 26 |
No, I am not mixing issues here. |
| 27 |
|
| 28 |
The quality problem is that we have too many developers. If you make |
| 29 |
community contributions easier, sane and more reliable (due to code |
| 30 |
review) then you solve several problems at once, because you need _less_ |
| 31 |
developers. Are you aware that we could potentially "pull" in hundreds |
| 32 |
of contributors who chose to work on their personal overlay instead of |
| 33 |
the gentoo tree? Are you aware that there are a lot of those people? |
| 34 |
|
| 35 |
Yes, it will slow down random commits. And sometimes that is what you |
| 36 |
need to keep good quality up. |
| 37 |
|
| 38 |
But as I said, this is currently not realistic, but not because it |
| 39 |
cannot be done. It can. And there are lots of projects that do. And I |
| 40 |
don't mean small projects. |
| 41 |
|
| 42 |
Most of the confusion comes from the fact that some gentoo devs have |
| 43 |
been doing this broken workflow for so long that they can barely imagine |
| 44 |
a workflow that is not broken. The other problems comes from the fact |
| 45 |
that a huge potential contributor base has withdrawn from contributing |
| 46 |
to the tree and now sticks to overlays. Those are our main problems, not |
| 47 |
tools. |
| 48 |
|
| 49 |
And because of that, a workflow transition will have to be executed |
| 50 |
step-wise. |
Archives