1 |
On Fri, 02 Nov 2018 15:20:16 +0100 Michał Górny wrote: |
2 |
> On Fri, 2018-11-02 at 01:27 +0300, Andrew Savchenko wrote: |
3 |
> > Hi! |
4 |
> > |
5 |
> > On Tue, 30 Oct 2018 08:18:58 +0100 Michał Górny wrote: |
6 |
> > > On Mon, 2018-10-29 at 03:57 +0300, Andrew Savchenko wrote: |
7 |
> > > > On Sun, 28 Oct 2018 19:29:28 +0100 Michał Górny wrote: |
8 |
> > > > > On Sun, 2018-10-28 at 01:38 +0300, Andrew Savchenko wrote: |
9 |
> > > > > > Hi all! |
10 |
> > > > > > |
11 |
> > > > > > The only blocker for EAPI 7 update is eutils inheritance, but it |
12 |
> > > > > > seems to be not used within the current eclass code, probably a |
13 |
> > > > > > remnant from older days. So it is removed. |
14 |
> > > > > > |
15 |
> > > > > > Looks like no other EAPI 7 specific changes needed. |
16 |
> > > > > > |
17 |
> > > > > |
18 |
> > > > > Please use -U99999 to include more context to the patches. |
19 |
> > > |
20 |
> > > I'm going to include a few 'easy cleanup' comments since EAPI 7 |
21 |
> > > is a good opportunity to improve the eclass. I'm going to skip horribly |
22 |
> > > bad design decisions since I suppose nobody cares. |
23 |
> > |
24 |
> > Should we really mix EAPI bump with full code review? |
25 |
> |
26 |
> Yes, for two reasons. |
27 |
> |
28 |
> Firstly, because an EAPI bump effectively requires reviewing all |
29 |
> the eclass logic for constraints imposed by the new EAPI. While |
30 |
> reviewing code, it is natural that people may notice other issues. |
31 |
> Ignoring them once noticed would be a waste of effort. |
32 |
|
33 |
EAPI update usually don't affect full ebuild scope. For EAPI 6->7 |
34 |
update grep is sufficient to find affected parts of the eclass. |
35 |
|
36 |
> Secondly, changes to frequently used eclass have a large overhead of |
37 |
> metadata cache updates. Given most of the listed issues are rather |
38 |
> trivial to fix, it would be wasteful to defer them for a second metadata |
39 |
> cache update. |
40 |
|
41 |
Not all eclasses are frequently used, including fortran-2 eclass. |
42 |
|
43 |
> > So I kindly ask you for future updates (from everyone, not just |
44 |
> > me) focus on review of the proposed changes instead of reviewing |
45 |
> > full code. Thank you for understanding. |
46 |
> |
47 |
> As explained above, the proposed change is meaningless without context |
48 |
> (as it affects how everything else in eclass works). If we were to |
49 |
> ignore context, we'd even ACK eclass changes that resulted in the eclass |
50 |
> immediately dying due to programmer's mistake. |
51 |
> |
52 |
> Finally, I'd like to point out that peer review is one of foundations |
53 |
> of open source. |
54 |
|
55 |
While peer review is important in many cases, the statement above |
56 |
is wrong. The free software (and not just open source and Gentoo |
57 |
is free software) founds on the four freedoms as defined by FSF. |
58 |
|
59 |
> Sadly, Gentoo has failed to embrace this, and right now reviews |
60 |
> of existing code are rather an exception than a rule. What |
61 |
> makes it even worse is that some developers are actively hostile to |
62 |
> the criticism of their code. |
63 |
|
64 |
Everything is good only within sane limits. While peer review is |
65 |
often useful, it may be harmful as well: |
66 |
|
67 |
1) It at least doubles human time required to do the job. And human |
68 |
resources are the only resources we are really short of. |
69 |
|
70 |
2) Sometimes it turns into bikeshedding, e.g. of how variables |
71 |
should be named or what indentation style should be used. |
72 |
|
73 |
3) Unreasonably long and complicated process for routine changes |
74 |
may discourage people from further contributions. Right now we have |
75 |
dozens of eclasses still on EAPI 6. I would prefer to see them |
76 |
EAPI 7 so they would not block EAPI 7 updates of dependent packages, |
77 |
rather than require them to underdo complete overhaul during EAPI 7 |
78 |
update effectively postponing it for a long time. |
79 |
|
80 |
Sometimes the best is the enemy of the good. |
81 |
|
82 |
Best regards, |
83 |
Andrew Savchenko |