On Sat, Jul 4, 2015 at 11:05 PM, Andrew Savchenko <birc...@gentoo.org> 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. Code review is good at a limited scope, e.g. for non-developers > where we have review anyway. > > Manpower issues aside, my perception of the project is that speed is valued over quality; and this has been the case for many many years. Its difficult to make a large change like "all commits require review", particularly for long-time contributors who are expecting to move quickly. I realize that a subset of the community wants quality and code review is certainly one way to improve quality. I'd be curious how many subprojects use review (I know infra did it informally, particularly when making changes to parts of the infrastructure that we were unfamiliar with; for learning purposes.) I'd also be curious what adoption of a code review system would be like if it was not required (but was available, and perhaps required for specific subprojects that adopt it.) -A > And as was already told in this thread, the best is the enemy of > the good. In no way we should delay git migration due to possible > git review. > > Best regards, > Andrew Savchenko >
