1 |
On 10/14/2011 09:11 PM, "Paweł Hajdan, Jr." wrote: |
2 |
> On 10/14/11 5:38 PM, Alec Warner wrote: |
3 |
>> I believe op's point is that there is no one to escalate the problem |
4 |
>> to; certainly the council members are not going to do the work |
5 |
>> themselves and we already have our best people on it. |
6 |
> |
7 |
> I'm aware of that. My point is that I think there are many scenarios in |
8 |
> which EAPI-4 + python.eclass can work, especially if it's used only for |
9 |
> few things in cases like www-client/chromium |
10 |
> |
11 |
> Because the python team takes _ages_ to do the transition that is |
12 |
> holding back many other packages, because they've made python.eclass |
13 |
> overly complex and now try to make it perfect, |
14 |
> |
15 |
> I'd just like to get an "OK" to enable EAPI-4 for that eclass. |
16 |
> |
17 |
> Please note that it's still up to dependent packages which EAPI they |
18 |
> use. If they break python.eclass with EAPI-4 they shouldn't update to |
19 |
> that EAPI. However, if there are packages using python.eclass that could |
20 |
> work fine with EAPI-4, it shouldn't be blocking them for *ages* |
21 |
> |
22 |
|
23 |
That would be an ok approach from my perspective: We could just change |
24 |
line 14 of python.eclass and let package maintainers report breakage as |
25 |
they increment EAPI. I am confident that nothing EAPI <= 3 would break. |
26 |
|
27 |
Is anyone (especially djc and the python herd members) opposed to this? |