1 |
El jue, 21-06-2012 a las 08:39 +0100, Ciaran McCreesh escribió: |
2 |
> On Thu, 21 Jun 2012 09:25:10 +0200 |
3 |
> Pacho Ramos <pacho@g.o> wrote: |
4 |
> > Then, looks clear to me that the way to get things approved in newer |
5 |
> > EAPIs is not clear enough as looks like a lot of devs (like me) don't |
6 |
> > know them (for example, when things to be added to EAPI need also a |
7 |
> > GLEP and a PMS diff, also the needing to get an implementation for any |
8 |
> > package manager). |
9 |
> |
10 |
> That's very much a judgement call. If a feature is "easy", low impact |
11 |
> and uncontroversial, you can ask for it on IRC, the mailing lists or |
12 |
> bugzilla, and chances are someone will do all the work for you. |
13 |
|
14 |
That cannot be the way of doing things, who is the once deciding a |
15 |
feature is "easy"? Is something like: |
16 |
https://bugs.gentoo.org/show_bug.cgi?id=357561 |
17 |
|
18 |
easy enough? Looks like it's getting so much time to get it done that we |
19 |
are now needing to rely on eclasses and manual removal to handle it. |
20 |
|
21 |
> If it's |
22 |
> a big feature with broad impact requiring lots of changes, you need to |
23 |
> do however much work is necessary such that a) the people working on |
24 |
> PMS understand it well enough to document it, b) developers understand |
25 |
> it well enough to know what it involves for them, c) the Council can |
26 |
> compare and contrast it with other proposals, and d) it can be |
27 |
> implemented. |
28 |
> |
29 |
> The "implement it in a package manager" thing is because of what |
30 |
> happened with REQUIRED_USE. It hadn't been implemented previously, and |
31 |
> as it turns out it has some fairly hefty usability issues. |
32 |
|
33 |
Look for example to multilib stuff, looks like mails explaining the |
34 |
issue and how tommy wants to fix it are not enough (I don't mean only |
35 |
the last thread about this problem, I remember he sending more mails |
36 |
explaining the issue months ago), Tommy is also providing PMS people an |
37 |
implementation... and now you come demanding more and more things. If |
38 |
all requirements would be clear from start, this shouldn't occur and all |
39 |
of us would save a lot of time and problems between us. |
40 |
|
41 |
> |
42 |
> > > > I also don't understand why Gentoo is forced to stick with old |
43 |
> > > > ways of doing things until new EAPI is approved |
44 |
> > > |
45 |
> > > That's not what's going on here. The issue is that there might be |
46 |
> > > one person who understands what "the new way of doing things", but |
47 |
> > > he hasn't told us what he thinks that is. Once we get a proper |
48 |
> > > explanation, getting an EAPI out doesn't take long. |
49 |
> > > |
50 |
> > |
51 |
> > But you must confess that old problems like multilib support, force |
52 |
> > package rebuilding or optional dep support are still pending while |
53 |
> > still needing and, the problem with the way things are discussed now |
54 |
> > is that some day anybody arises the problem again, other one demands |
55 |
> > more things to be provided, a discussion starts, the problem gets |
56 |
> > stalled... one year later the same problem arises again. There is |
57 |
> > clearly a lack of information to the rest of developers about how to |
58 |
> > propose anything to get accepted for next EAPI. |
59 |
> |
60 |
> The reason those are still pending is because no-one knows what the |
61 |
> *problem* is, let alone the solution. |
62 |
|
63 |
Seriously, don't you know what are the problems of current way of |
64 |
handling emul packages? :O |
65 |
|
66 |
> That's not an EAPI issue, it's a |
67 |
> developers saying "I want a flying unicorn!" issue. |
68 |
> |
69 |
> > Then, you accept exherbo is not forced to *only* follow EAPI while you |
70 |
> > force Gentoo and portage to only support features approved in an EAPI? |
71 |
> |
72 |
> I think you have a severe misunderstanding of what the EAPI process is |
73 |
> about here... It's not about forcing anything. The point of the EAPI |
74 |
> process is to allow Gentoo to roll things out without requiring |
75 |
> developers to rewrite all their ebuilds every few months (which |
76 |
> happens on Exherbo, incidentally), and without breaking user systems. |
77 |
> |
78 |
|
79 |
Then, I guess we could have something like GEAPI that would require only |
80 |
agreement between gentoo people (and people wanting to reach a |
81 |
consensus) that would also prevent people from needing to rewrite their |
82 |
ebuilds from time to time? |
83 |
|
84 |
Don't you see this way of handling things, with such and obscure way of |
85 |
getting things accepted for every EAPI is really hurting us? If all of |
86 |
us would want to reach consensus it wouldn't be so problematic but, when |
87 |
some people is simply waiting every proposal (even with implementation |
88 |
and after more tries to get it accepted) to ask them for more and more |
89 |
work and, when anybody ask for help to accomplish that, the same one |
90 |
refuses to help if he is not payed for that, this only causes Gentoo to |
91 |
lack some important features for ages. |