1 |
On Thu, 21 Jun 2012 19:15:02 +0800 |
2 |
Patrick Lauer <patrick@g.o> wrote: |
3 |
> > Then, looks clear to me that the way to get things approved in newer |
4 |
> > EAPIs is not clear enough as looks like a lot of devs (like me) |
5 |
> > don't know them (for example, when things to be added to EAPI need |
6 |
> > also a GLEP and a PMS diff, also the needing to get an |
7 |
> > implementation for any package manager). Is this documented in some |
8 |
> > place? |
9 |
> No, and this is a rather random ad-hoc requirement that hasn't been |
10 |
> specified before. |
11 |
|
12 |
It's dependent upon the level of complexity of the work, and whether or |
13 |
not anyone on the PMS team understands it enough to be able to do the |
14 |
work themselves. As far as I know, none of us do on this one, so it's |
15 |
down to whoever wants it to educate us enough that we can get it done... |
16 |
|
17 |
> All previous EAPI processes went through some debate with dev-portage@ |
18 |
> and the other involved people (mostly pkgcore/ferringb and |
19 |
> paludis/ciaranm), then the proposal got handed to council to vote on, |
20 |
> and if council was happy that proposal was hammered into PMS and the |
21 |
> new EAPI published. Most of the time new features had a crude |
22 |
> approximation of a patch for PMS available so that the documentation |
23 |
> updates were done in a timely manner. |
24 |
|
25 |
Actually, we've been passing pretty much final PMS patches to the |
26 |
Council to vote on. |
27 |
|
28 |
> I have no idea why Ciaran is trying to redefine the process now |
29 |
> suddenly and why people are taking this nonsense seriously. |
30 |
|
31 |
I'm not. |
32 |
|
33 |
> I would say PMS team accepts what council signs off ... or am I seeing |
34 |
> the order wrong here? |
35 |
|
36 |
The PMS team makes suggestions to the Council, and the Council accepts |
37 |
a subset of those. The Council can also suggest that the PMS team looks |
38 |
at a particular feature, but as Gentoo has no mechanism in place for |
39 |
forcing work to get done, that only works if there's someone with both |
40 |
the time and the knowledge to figure it out. |
41 |
|
42 |
> So, the normal way to get a feature into the next EAPI is ... write a |
43 |
> specification to the best of your capabilities, present it here, when |
44 |
> people are done bashing it ask PMS people to help you prepare a PMS |
45 |
> patch so that you can suggest it to Council |
46 |
|
47 |
Yup, and for difficult cases like the ones under discussion, a part of |
48 |
presenting it is to demo a working implementation on real packages so |
49 |
that we gain real world experience of the feature. |
50 |
|
51 |
It's also important to note that "the best of your capabilities" may |
52 |
not be anywhere near enough for the PMS people or the package mangler |
53 |
people to do the remainder of the work. |
54 |
|
55 |
> and then it's mostly a |
56 |
> matter of waiting until the next EAPI is finalized (which currently |
57 |
> runs at a glacial pace of about one EAPI a year as far as I remember) |
58 |
|
59 |
I like how you simultaneously troll both sides of that issue. Weren't |
60 |
you previously claiming there were too many EAPIs and that we shouldn't |
61 |
have lots of new ones? |
62 |
|
63 |
-- |
64 |
Ciaran McCreesh |