| 1 |
On Sat, Jul 4, 2015 at 11:05 PM, Andrew Savchenko <bircoph@g.o> |
| 2 |
wrote: |
| 3 |
|
| 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 |
Code review is good at a limited scope, e.g. for non-developers |
| 15 |
> where we have review anyway. |
| 16 |
> |
| 17 |
> |
| 18 |
Manpower issues aside, my perception of the project is that speed is valued |
| 19 |
over quality; and this has been the case for many many years. Its difficult |
| 20 |
to make a large change like "all commits require review", particularly for |
| 21 |
long-time contributors who are expecting to move quickly. |
| 22 |
|
| 23 |
I realize that a subset of the community wants quality and code review is |
| 24 |
certainly one way to improve quality. I'd be curious how many subprojects |
| 25 |
use review (I know infra did it informally, particularly when making |
| 26 |
changes to parts of the infrastructure that we were unfamiliar with; for |
| 27 |
learning purposes.) |
| 28 |
|
| 29 |
I'd also be curious what adoption of a code review system would be like if |
| 30 |
it was not required (but was available, and perhaps required for specific |
| 31 |
subprojects that adopt it.) |
| 32 |
|
| 33 |
-A |
| 34 |
|
| 35 |
|
| 36 |
> And as was already told in this thread, the best is the enemy of |
| 37 |
> the good. In no way we should delay git migration due to possible |
| 38 |
> git review. |
| 39 |
> |
| 40 |
> Best regards, |
| 41 |
> Andrew Savchenko |
| 42 |
> |
Archives