On 04/17/2015 02:26 PM, Andrew Savchenko wrote: > On Fri, 17 Apr 2015 13:14:49 +0200 hasufell wrote: >> On 04/17/2015 01:00 PM, Andrew Savchenko wrote: >>> On Fri, 17 Apr 2015 12:33:06 +0200 Alexander Berntsen wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>> On 15/04/15 15:02, Peter Stuge wrote: >>>>> the threshold to become a developer with write access to the >>>>> gentoo repo is very high >>>> LOL. No. It's way too low, given our review-less workflow in which any >>>> dev can do essentially whatever they want. >>> >>> The only net results from strict review workflow (when each commit >>> of each dev must be reviewed and approved by at least N devs) are >>> tons of bikeshedding, real quality improvement is marginal, because >>> people are working in different areas anyway. And if you will >>> consider, that strict review will require N more times effort and >>> spent time, actual quality of the tree will drop almost N times, >>> because number of man hours spent on Gentoo is approximately >>> constant with the same number of devs. >> >> If you have followed the recent discussions about gentoos organizational >> structure, review workflow and overlay situation you would know that >> there is a pretty simple solution for this problem. > > I have followed them and I have seen no solution usable in real > world. >
The solution is that for example the ruby project assigns a few reviewers (e.g. project lead) and if someone wants to bump ruby packages, he submits a pull request and the assignee is going to be the ruby project. What's the problem? Do you think the usb-subsystem maintainer of the kernel is going to fiddle with the cryptography subsystem all by himself? That's not the case. And that's why the linux kernel workflow works: competence, subsystems and trust. All that is done in real world. And there are tons of tools to automated such a workflow easily without dumping everything to a single mailing list. Global reviews will only happen when stuff is actually of global importance, like non-trivial eclass changes or far-reaching technical decisions. So please do some research first before doing broad statements about what kind of workflow is possible. Other distros successfully use such workflows.
