On 07/09/2015 09:19 AM, Andrew Savchenko wrote: > On Mon, 06 Jul 2015 19:20:14 +0200 hasufell wrote: >> On 07/05/2015 08:05 AM, Andrew Savchenko 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. >>> >> >> People misinterpret "manpower". If we successfully switch to a >> code-review approach, then we will need _less_ manpower in the sense of >> actual gentoo developers. > > You're mixing different issues here. Code review process for > contributors (outside of development team) will indeed save time > and manpower. But code review for each developer commit will kill > time and effort undoubtedly, while net quality will have little to > negligible improvement. >
No, I am not mixing issues here. The quality problem is that we have too many developers. If you make community contributions easier, sane and more reliable (due to code review) then you solve several problems at once, because you need _less_ developers. Are you aware that we could potentially "pull" in hundreds of contributors who chose to work on their personal overlay instead of the gentoo tree? Are you aware that there are a lot of those people? Yes, it will slow down random commits. And sometimes that is what you need to keep good quality up. But as I said, this is currently not realistic, but not because it cannot be done. It can. And there are lots of projects that do. And I don't mean small projects. Most of the confusion comes from the fact that some gentoo devs have been doing this broken workflow for so long that they can barely imagine a workflow that is not broken. The other problems comes from the fact that a huge potential contributor base has withdrawn from contributing to the tree and now sticks to overlays. Those are our main problems, not tools. And because of that, a workflow transition will have to be executed step-wise.
