1 |
On Sun, Sep 19, 2010 at 12:14 PM, Matti Bickel <mabi@g.o> wrote: |
2 |
> I'm a couple weeks late with this, but here goes: |
3 |
> from my failed attempts at reviving GLEP33 grow a discussion with |
4 |
> ferringb on IRC about how to get what I wanted anyway :) |
5 |
|
6 |
I've placed my immediate feedback in CVS: |
7 |
|
8 |
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/users/antarus/projects/gleps/glep-XX.txt?r1=1.1&r2=1.2 |
9 |
|
10 |
I will split the remaining commentary up into two sections: |
11 |
|
12 |
General Idea Feedback (call these non-editor related) and editorial |
13 |
feedback (generally segments you should add to the GLEP for editorial |
14 |
reasons.) |
15 |
|
16 |
> |
17 |
> We agreed that having eclasses specific to a package located someplace |
18 |
> near the actual ebuilds was beneficial and should be supported by PMs |
19 |
> somehow. Someplace and somehow are specified along some other details in |
20 |
> the attached proposed GLEP. |
21 |
|
22 |
Feedback: |
23 |
I believe the biggest reason to have per-package eclasses is the following: |
24 |
|
25 |
1) It limits how users can use an eclass. |
26 |
a) This makes mis-using eclasses harder to do; Interfaces that are |
27 |
hard to use incorrectly are good. |
28 |
b) It means changing an eclass affects fewer packages. It is |
29 |
currently difficult to control eclass consumers in the current model. |
30 |
(anyone can use any eclass.) |
31 |
c) It means eclass changes are easier to test. |
32 |
|
33 |
I think the GLEP attempts to over-blow the actual impact that its |
34 |
proposed changes may have. For instance I do not think per-package |
35 |
eclasses will drastically reduce the number of eclasses in the global |
36 |
eclass directory. It will not make overlays easier to use (possibly |
37 |
harder..actually.) |
38 |
|
39 |
Plus the number of eclasses that will move to per-package is likely |
40 |
few (the GLEP itself only notes three.) |
41 |
|
42 |
> |
43 |
> I'm posting this for review by the wider community, at the same time |
44 |
> asking the GLEP editors (antarus? pva?) for guidance on the formalities. |
45 |
> I gather the GLEP should get a number and be uploaded in CVS somewhere, |
46 |
> as well as appear on the GLEP project page. |
47 |
|
48 |
Editorial: |
49 |
The proposal is vaguely similar to GLEP 33. There is also an existing |
50 |
implementation of per-package eclasses called eblits (used in glibc, |
51 |
possibly in other places.) The GLEP should refer to these (link to |
52 |
GLEP 33, if there is a page describing eblits; link to that as well.) |
53 |
The GLEP should also discuss why GLEP 33 and eblits are not the best |
54 |
implementation of this idea. |
55 |
|
56 |
If the GLEP makes claims such as 'The implementation will improve X or |
57 |
reduce Y by Z%' the GLEP should cite sources, data, or make some kind |
58 |
of argument as to why that is the case. For instance the GLEP refers |
59 |
to 'distributing ebuilds in overlays will be easier' but fails to |
60 |
discuss how it is easier in this new system. When thinking about |
61 |
these types of things; try to break them down into something |
62 |
measurable. For instance: "With the old system there were 5 |
63 |
individual steps, the new system only has 3." |
64 |
|
65 |
The GLEP makes claims about how the per-package eclasses *could* be |
66 |
made part of the Manifest format. The GLEP should not focus on could. |
67 |
Either the per-package eclasses are part of the manifest code (per |
68 |
this GLEP) or they are not. If the GLEP dictates they are to be |
69 |
included in manifests the GLEP should discuss how exactly that will |
70 |
work (what types, checksums, etc..) If the eclasses are not required |
71 |
to be manifested then the GLEP should not tout that as an advantage |
72 |
over the status quo. |
73 |
|
74 |
> |
75 |
> So, yeah, what do you think? Is it worth it? Can the draft be improved? |
76 |
> I'm specifically interested in the amount of work involved in supporting |
77 |
> something like the thing laid out in the GLEP in our current PMs. |
78 |
> |
79 |
|
80 |
Any dev can check stuff into other dev's individual CVS space. Feel |
81 |
free to edit the eclass in my devspace if you wish. I think there is |
82 |
some automation on the actual GLEP webspace now (that htmlifies GLEPS) |
83 |
so I am avoiding that space cause I forgot how exactly the automation |
84 |
works ;)) |