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