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. However, this does not and cannot happen over night since it requires a shift of thinking and a change of culture, involving the whole community. But if we just want to add more independent committers to the core gentoo tree, then we are definitely making quality worse. I'm not particularly sure that an alternative review-based workflow can work here, given that our workflow has been broken for quite a few years. Such things become a strong habit and may leave some of our developers in confusion. But it could start (and already has, afaik) with project-internal requirements (e.g. kde project demanding reviews). When the different projects increase workflow strictness, it will increase overall strictness as well. > Code review is good at a limited scope, e.g. for non-developers > where we have review anyway. > This is not enough to maintain high quality. I've seen some ebuilds in user overlays which have higher quality than their gx86 counterpart. However, that said... I don't think it currently makes sense to enforce a strict global review workflow. However, we should encourage gentoo-internal projects to become more strict (and e.g. only have one or two "pushers").
