1 |
On 04/17/2015 04:33 PM, Andrew Savchenko wrote: |
2 |
> On Fri, 17 Apr 2015 14:50:00 +0200 hasufell wrote: |
3 |
>>>> If you have followed the recent discussions about gentoos organizational |
4 |
>>>> structure, review workflow and overlay situation you would know that |
5 |
>>>> there is a pretty simple solution for this problem. |
6 |
>>> |
7 |
>>> I have followed them and I have seen no solution usable in real |
8 |
>>> world. |
9 |
>>> |
10 |
>> |
11 |
>> The solution is that for example the ruby project assigns a few |
12 |
>> reviewers (e.g. project lead) and if someone wants to bump ruby |
13 |
>> packages, he submits a pull request and the assignee is going to be the |
14 |
>> ruby project. What's the problem? |
15 |
> |
16 |
> The problem is double effort: previously one developer effort was |
17 |
> needed, now effort is doubled at least: reviewers must dig into |
18 |
> details how submitted code works, test it and only then commit. Now |
19 |
> remember that reviewers are also developers. This means that pull |
20 |
> requests will hang for weeks, months, forever due to a lack of time. |
21 |
> On top of all this thinks about maintainer-needed packages or |
22 |
> packages that can't be categorised into some single project, e.g. |
23 |
> *-misc categories. |
24 |
> |
25 |
|
26 |
Not really. The depth of reviews will depend on |
27 |
a) what package/subsystem is it? Is it just an end-user app, is it a |
28 |
library, is it toolchain...? |
29 |
b) who sent the pull request? Was it a random user or a developer I |
30 |
trust? In the latter case I might just check that repoman doesn't choke |
31 |
and pull the stuff in. |
32 |
|
33 |
Currently... some gentoo projects who enforce strict reviews have very |
34 |
poor workflow. Because bugzilla is completely useless for reviews, |
35 |
people end up doing IRC reviews. IRC is not a proper review platform |
36 |
either, especially not for drive-by contributions or people who don't |
37 |
have time to read 500 lines of scrollback or whatever. |
38 |
|
39 |
>> Do you think the usb-subsystem maintainer of the kernel is going to |
40 |
>> fiddle with the cryptography subsystem all by himself? That's not the |
41 |
>> case. And that's why the linux kernel workflow works: competence, |
42 |
>> subsystems and trust. |
43 |
> |
44 |
> As I pointed above comparision of Gentoo with Linux kernel is |
45 |
> invalid. We have different resources. Another argument that |
46 |
> connectivity between subsystems is much higher in the Linux kernel. |
47 |
> |
48 |
|
49 |
It is perfectly valid. It is a huge system just like gentoo. The |
50 |
workflow in detail might differ, but in the end we deliver a system that |
51 |
should be coherent and work. We have little to no QA on that and our |
52 |
workflow is one of the fundamental things that need to be fixed if we |
53 |
want that to change. |
54 |
|
55 |
If people say they don't care about it, that's fine. But then I'm not |
56 |
sure what we need a QA team for, except for running repoman on the tree. |
57 |
Unfortunately, repoman cannot tell you if an ebuild wipes your hard |
58 |
drive in pkg_postinst. |
59 |
|
60 |
>> All that is done in real world. And there are tons of tools to automated |
61 |
>> such a workflow easily without dumping everything to a single mailing list. |
62 |
> |
63 |
> Reviews cannot be automated. A human being is still needed to read, |
64 |
> understand and test proposed code. All tools like pull requests and |
65 |
> so automate only a small bit of real work. |
66 |
> |
67 |
|
68 |
You misread. I said the WORKFLOW can be automated. There are tools to do |
69 |
that. Neither bugzilla, nor CVS is one of them. We have enough google |
70 |
employees here in gentoo, who should be fairly familiar with these things. |
71 |
|
72 |
>> Global reviews will only happen when stuff is actually of global |
73 |
>> importance, like non-trivial eclass changes or far-reaching technical |
74 |
>> decisions. |
75 |
> |
76 |
> We already have that with gentoo-dev mail list. And I'm happy with |
77 |
> current solution. If you can't handle patchset from e-mails, learn |
78 |
> houw to use tools, e.g. quilt. |
79 |
> |
80 |
|
81 |
You misread again. I didn't say we lack a tool for global reviews. I |
82 |
said that ebuild reviews must not happen randomly on a single mailing |
83 |
list. That would be chaos. |
84 |
|
85 |
>> Other distros successfully use such workflows. |
86 |
> |
87 |
> Other distros are binary based. |
88 |
|
89 |
Last I checked exherbo is source based and has USE flags. |