1 |
El jue, 21-06-2012 a las 11:27 +0200, Alec Warner escribió: |
2 |
> On Thu, Jun 21, 2012 at 9:25 AM, Pacho Ramos <pacho@g.o> wrote: |
3 |
> > El jue, 21-06-2012 a las 08:00 +0100, Ciaran McCreesh escribió: |
4 |
> >> On Thu, 21 Jun 2012 08:08:55 +0200 |
5 |
> >> Pacho Ramos <pacho@g.o> wrote: |
6 |
> >> > Also, if I remember correctly, Tommy asked for this some months ago, |
7 |
> >> > you asked for what he sent some days ago and now you require more and |
8 |
> >> > more work to delay things to be implemented. |
9 |
> >> |
10 |
> >> I still haven't seen a clear description of exactly what should be |
11 |
> >> changed and why. I've also not seen a description of exactly what |
12 |
> >> problem is being solved, nor a discussion of the relative merits of |
13 |
> >> implementing a solution to whatever that problem is. All I've seen is a |
14 |
> >> mess of code that "gets it working" in Portage (which isn't the same as |
15 |
> >> "implements it for Portage") and a big wall of text that contains lots |
16 |
> >> that no-one needs to know and little of what's important. This needs to |
17 |
> >> go through the GLEP process, and it needs a PMS diff. |
18 |
> >> |
19 |
> >> In case you're not aware, the first time Gentoo did multilib, it was |
20 |
> >> done as a series of random changes to Portage that no-one really |
21 |
> >> thought through or understood. As you can see, that didn't work... |
22 |
> >> |
23 |
> > |
24 |
> > Then, looks clear to me that the way to get things approved in newer |
25 |
> > EAPIs is not clear enough as looks like a lot of devs (like me) don't |
26 |
> > know them (for example, when things to be added to EAPI need also a GLEP |
27 |
> > and a PMS diff, also the needing to get an implementation for any |
28 |
> > package manager). Is this documented in some place? If not, I think it |
29 |
> > should be documented and, of course, it should be done by PMS team if |
30 |
> > possible as they clearly know what they expect to get for approval if |
31 |
> > needed since, I discussed some days ago, council will simply accept some |
32 |
> > specific features to be included in next eapi once they are accepted by |
33 |
> > PMS team. That way, we could save a lot of time, know what steps are |
34 |
> > pending, try to ask for help for some specific steps and, finally, get |
35 |
> > it discussed in PMS people providing all what is needed. |
36 |
> > |
37 |
> > |
38 |
> >> > I also don't understand why Gentoo is forced to stick with old ways |
39 |
> >> > of doing things until new EAPI is approved |
40 |
> >> |
41 |
> >> That's not what's going on here. The issue is that there might be one |
42 |
> >> person who understands what "the new way of doing things", but he |
43 |
> >> hasn't told us what he thinks that is. Once we get a proper |
44 |
> >> explanation, getting an EAPI out doesn't take long. |
45 |
> >> |
46 |
> > |
47 |
> > But you must confess that old problems like multilib support, force |
48 |
> > package rebuilding or optional dep support are still pending while still |
49 |
> > needing and, the problem with the way things are discussed now is that |
50 |
> > some day anybody arises the problem again, other one demands more things |
51 |
> > to be provided, a discussion starts, the problem gets stalled... one |
52 |
> > year later the same problem arises again. There is clearly a lack of |
53 |
> > information to the rest of developers about how to propose anything to |
54 |
> > get accepted for next EAPI. |
55 |
> |
56 |
> I'm not following you here. |
57 |
> |
58 |
> 1) Usually features need a reference implementation. |
59 |
> 2) For portage, there are like 3-5 people who know portage well enough |
60 |
> to write that for you. |
61 |
> 3) You generally have to convince them to do it before you can move forward. |
62 |
> 4) Most features never even get a reference implementation. |
63 |
> |
64 |
> There is this vague idea that you can just propose something; get |
65 |
> consensus on the ML, everyone goes to implement it, and then it works |
66 |
> just as designed. That is usually called the 'waterfall' model and its |
67 |
> really hard to do correctly. |
68 |
> |
69 |
> What I imagine the process is: |
70 |
> |
71 |
> 1) Submit an idea to the ML; you just need feedback (not consensus, |
72 |
> which is likely impossible for non-trivial ideas.) |
73 |
> 1.1) Your idea could be a GLEP, but I don't think a GLEP is strictly required. |
74 |
> 2) Take feedback from step one and make an initial implementation. You |
75 |
> will likely find some assumptions in your 'design' from step one were |
76 |
> wrong, as well as other implementation issues (UI, performance, etc.) |
77 |
> 3) Modify your idea to address the problems in 2. |
78 |
> 4) Modify your implementation to address the problems in 2. |
79 |
> 5) Repeat steps 2-4 a few times until you have solved all the 'big' problems. |
80 |
> 6) Submit a diff to PMS outlining how the package manager behavior is |
81 |
> changed by your feature. This generally needs to be specific enough so |
82 |
> that other package manager authors can implement the feature. |
83 |
> 7) Submit a devmanual patch telling users how to use the feature. |
84 |
> |
85 |
> Most people fail at step two; usually because they try to get |
86 |
> 'consensus' at step one, which is stupid and a waste of time. There |
87 |
> are a few hundred people on this list; we will never all agree, on |
88 |
> basically anything. So take the feedback people give you and do |
89 |
> something with it. |
90 |
> |
91 |
|
92 |
OK thanks :) What I was trying to show is that this process is not clear |
93 |
enough, you even need to say that you "imagine" that it's the process, |
94 |
and looks pretty reasonable but, if that process is kept undocumented, |
95 |
we are doomed to revive the problem again and again |
96 |
|
97 |
About trying to get a consensus, I think it's wanted to not waste time |
98 |
reimplementing things a lot of times. Think for example in ABI_SLOT |
99 |
stuff, we reached some small consensus about, at least, use SLOT/SUBSLOT |
100 |
approach, that will probably save a bit of time to people making the |
101 |
implementation as he won't need to firstly implemente ABI_SLOT way, |
102 |
later get it rejected again and, finally, re-implement it with |
103 |
SLOT/SUBSLOT. The idea is to try to help people doing the huge work of |
104 |
getting the implementation to save as much time as possible. |
105 |
|
106 |
But I also understand your point as looks like usually it's really |
107 |
difficult to reach consensus :/ |
108 |
|
109 |
> > |
110 |
> >> The main problem here isn't even EAPI related. Ebuild developers don't |
111 |
> >> even know what they'll be expected, required or able to do for multilib. |
112 |
> >> |
113 |
> >> > while Exherbo is free to implement and use things like that special |
114 |
> >> > way of handling DEPENDENCIES without waiting for any EAPI to be |
115 |
> >> > accepted... |
116 |
> >> |
117 |
> >> The DEPENDENCIES proposal predates Exherbo. Gentoo originally didn't |
118 |
> >> have it because Portage couldn't implement it. Now it doesn't have it |
119 |
> >> because it's too controversial to get it approved. |
120 |
> > |
121 |
> > It was only a example, but thanks for the info :) |
122 |
> > |
123 |
> >> Exherbo does have it |
124 |
> >> because it was carefully discussed, compared to alternatives, planned |
125 |
> >> out, tested, accepted by the expendable figurehead, and then rolled out. |
126 |
> >> |
127 |
> >> > or maybe I am wrong and people is able to use any PM manager |
128 |
> >> > compliant with EAPI on exherbo without issues? |
129 |
> >> |
130 |
> >> If anyone ever manages to come up with another package mangler that can |
131 |
> >> get close to implementing what Exherbo needs, then sure. |
132 |
> >> |
133 |
> > |
134 |
> > Then, you accept exherbo is not forced to *only* follow EAPI while you |
135 |
> > force Gentoo and portage to only support features approved in an EAPI? |
136 |
> > |
137 |
> |
138 |
> Portage can use whatever EAPIs portage wishes to publish (Zac has |
139 |
> published portage specific EAPIs in the past.) Generally in gentoo-x86 |
140 |
> you can only use council approved EAPIs; so if portage was to publish |
141 |
> something like 'portage-1' you would have to get council approval to |
142 |
> use it in Gentoo-x86. It seems like a reasonable request to me, why |
143 |
> not talk to them about it. |
144 |
|
145 |
Didn't know that it was allowed. Thanks a lot for the information :) |
146 |
|
147 |
> |
148 |
> The reason exherbo can 'do whatever they want' is because the project |
149 |
> is marketed that way. Seriously, go to Exherbo.org and look at the |
150 |
> 'Why' section. Reason 2 is 'we need to break stuff whenever we feel it |
151 |
> is beneficial.' Gentoo is not marketed that way to our users. We |
152 |
> 'generally promise' backwards compat for 6-12 months. |
153 |
> |
154 |
> If we randomly added stuff to portage without being bound by EAPI then |
155 |
> we end up breaking stuff unintentionally all the time when rolling out |
156 |
> features. |
157 |
> |
158 |
> -A |
159 |
> |
160 |
> |
161 |
|
162 |
Well, I was more thinking on having our own "EAPIs", but I see I didn't |
163 |
explain it properly in previous mail, sorry |