| 1 |
On Fri, 17 Apr 2015 14:50:00 +0200 hasufell wrote: |
| 2 |
> >> If you have followed the recent discussions about gentoos organizational |
| 3 |
> >> structure, review workflow and overlay situation you would know that |
| 4 |
> >> there is a pretty simple solution for this problem. |
| 5 |
> > |
| 6 |
> > I have followed them and I have seen no solution usable in real |
| 7 |
> > world. |
| 8 |
> > |
| 9 |
> |
| 10 |
> The solution is that for example the ruby project assigns a few |
| 11 |
> reviewers (e.g. project lead) and if someone wants to bump ruby |
| 12 |
> packages, he submits a pull request and the assignee is going to be the |
| 13 |
> ruby project. What's the problem? |
| 14 |
|
| 15 |
The problem is double effort: previously one developer effort was |
| 16 |
needed, now effort is doubled at least: reviewers must dig into |
| 17 |
details how submitted code works, test it and only then commit. Now |
| 18 |
remember that reviewers are also developers. This means that pull |
| 19 |
requests will hang for weeks, months, forever due to a lack of time. |
| 20 |
On top of all this thinks about maintainer-needed packages or |
| 21 |
packages that can't be categorised into some single project, e.g. |
| 22 |
*-misc categories. |
| 23 |
|
| 24 |
> Do you think the usb-subsystem maintainer of the kernel is going to |
| 25 |
> fiddle with the cryptography subsystem all by himself? That's not the |
| 26 |
> case. And that's why the linux kernel workflow works: competence, |
| 27 |
> subsystems and trust. |
| 28 |
|
| 29 |
As I pointed above comparision of Gentoo with Linux kernel is |
| 30 |
invalid. We have different resources. Another argument that |
| 31 |
connectivity between subsystems is much higher in the Linux kernel. |
| 32 |
|
| 33 |
> All that is done in real world. And there are tons of tools to automated |
| 34 |
> such a workflow easily without dumping everything to a single mailing list. |
| 35 |
|
| 36 |
Reviews cannot be automated. A human being is still needed to read, |
| 37 |
understand and test proposed code. All tools like pull requests and |
| 38 |
so automate only a small bit of real work. |
| 39 |
|
| 40 |
> Global reviews will only happen when stuff is actually of global |
| 41 |
> importance, like non-trivial eclass changes or far-reaching technical |
| 42 |
> decisions. |
| 43 |
|
| 44 |
We already have that with gentoo-dev mail list. And I'm happy with |
| 45 |
current solution. If you can't handle patchset from e-mails, learn |
| 46 |
houw to use tools, e.g. quilt. |
| 47 |
|
| 48 |
> So please do some research first before doing broad statements about |
| 49 |
> what kind of workflow is possible. |
| 50 |
|
| 51 |
I already done such research and my conclusion is that it can't be |
| 52 |
fundamentally changed. Only small improvements here and there are |
| 53 |
possible. |
| 54 |
|
| 55 |
> Other distros successfully use such workflows. |
| 56 |
|
| 57 |
Other distros are binary based. They don't have USE flags, they |
| 58 |
don't have plenty of different compilers and environments. All they |
| 59 |
do is package building with predefined set of options in a fixed |
| 60 |
environment for each arch. Gentoo is much more complex than that. |
| 61 |
You can compare only apples to apples, not apples to plane. |
| 62 |
|
| 63 |
Best regards, |
| 64 |
Andrew Savchenko |
Archives