1 |
El jue, 21-06-2012 a las 19:15 +0800, Patrick Lauer escribió: |
2 |
> On 06/21/12 15:25, Pacho Ramos 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 |
> >> I still haven't seen a clear description of exactly what should be |
10 |
> >> changed and why. I've also not seen a description of exactly what |
11 |
> >> problem is being solved, nor a discussion of the relative merits of |
12 |
> >> implementing a solution to whatever that problem is. All I've seen is a |
13 |
> >> mess of code that "gets it working" in Portage (which isn't the same as |
14 |
> >> "implements it for Portage") and a big wall of text that contains lots |
15 |
> >> that no-one needs to know and little of what's important. This needs to |
16 |
> >> go through the GLEP process, and it needs a PMS diff. |
17 |
> >> |
18 |
> >> In case you're not aware, the first time Gentoo did multilib, it was |
19 |
> >> done as a series of random changes to Portage that no-one really |
20 |
> >> thought through or understood. As you can see, that didn't work... |
21 |
> >> |
22 |
> > Then, looks clear to me that the way to get things approved in newer |
23 |
> > EAPIs is not clear enough as looks like a lot of devs (like me) don't |
24 |
> > know them (for example, when things to be added to EAPI need also a GLEP |
25 |
> > and a PMS diff, also the needing to get an implementation for any |
26 |
> > package manager). Is this documented in some place? |
27 |
> No, and this is a rather random ad-hoc requirement that hasn't been |
28 |
> specified before. |
29 |
> |
30 |
> All previous EAPI processes went through some debate with dev-portage@ |
31 |
> and the other involved people (mostly pkgcore/ferringb and |
32 |
> paludis/ciaranm), then the proposal got handed to council to vote on, |
33 |
> and if council was happy that proposal was hammered into PMS and the new |
34 |
> EAPI published. Most of the time new features had a crude approximation |
35 |
> of a patch for PMS available so that the documentation updates were done |
36 |
> in a timely manner. |
37 |
> |
38 |
> I have no idea why Ciaran is trying to redefine the process now suddenly |
39 |
> and why people are taking this nonsense seriously. |
40 |
|
41 |
I take it seriously because looks like, effectively, this is blocking |
42 |
things. I remember when I first asked for an "easy" way of trying to |
43 |
allow administrator of Gentoo machines to easily handling all that |
44 |
needed rebuilds after updating: |
45 |
https://bugs.gentoo.org/show_bug.cgi?id=413619 |
46 |
|
47 |
Zac kindly pointed me to original bug: |
48 |
https://bugs.gentoo.org/show_bug.cgi?id=192319 |
49 |
|
50 |
I knew about that bug report but, as it was still pending after years, I |
51 |
thought there were technical issues making it hard to fix and, then, I |
52 |
tried to propose and easier solution at least until best one can be |
53 |
implemented. Then, if you remember the thread I opened here some weeks |
54 |
ago about this issue, you will see how things moved, even when Zac is |
55 |
already working on getting an implementation I am really worried about, |
56 |
even after Zac offering his work and time to get an implementation, when |
57 |
he offers it, Ciaran will reject it with some other excuse :( |
58 |
|
59 |
> |
60 |
> > If not, I think it |
61 |
> > should be documented and, of course, it should be done by PMS team if |
62 |
> > possible as they clearly know what they expect to get for approval if |
63 |
> > needed since, I discussed some days ago, council will simply accept some |
64 |
> > specific features to be included in next eapi once they are accepted by |
65 |
> > PMS team. That way, we could save a lot of time, know what steps are |
66 |
> > pending, try to ask for help for some specific steps and, finally, get |
67 |
> > it discussed in PMS people providing all what is needed. |
68 |
> I would say PMS team accepts what council signs off ... or am I seeing |
69 |
> the order wrong here? |
70 |
> |
71 |
> |
72 |
> So, the normal way to get a feature into the next EAPI is ... write a |
73 |
> specification to the best of your capabilities, present it here, when |
74 |
> people are done bashing it ask PMS people to help you prepare a PMS |
75 |
> patch so that you can suggest it to Council, and then it's mostly a |
76 |
> matter of waiting until the next EAPI is finalized (which currently runs |
77 |
> at a glacial pace of about one EAPI a year as far as I remember) |
78 |
> |
79 |
> |
80 |
> Take care, |
81 |
> |
82 |
> Patrick |
83 |
> |
84 |
> |