On 10/14/2011 09:11 PM, "Paweł Hajdan, Jr." wrote:
> On 10/14/11 5:38 PM, Alec Warner wrote:
>> I believe op's point is that there is no one to escalate the problem
>> to; certainly the council members are not going to do the work
>> themselves and we already have our best people on it.
> 
> I'm aware of that. My point is that I think there are many scenarios in
> which EAPI-4 + python.eclass can work, especially if it's used only for
> few things in cases like www-client/chromium
> 
> Because the python team takes _ages_ to do the transition that is
> holding back many other packages, because they've made python.eclass
> overly complex and now try to make it perfect,
> 
> I'd just like to get an "OK" to enable EAPI-4 for that eclass.
> 
> Please note that it's still up to dependent packages which EAPI they
> use. If they break python.eclass with EAPI-4 they shouldn't update to
> that EAPI. However, if there are packages using python.eclass that could
> work fine with EAPI-4, it shouldn't be blocking them for *ages*
> 

That would be an ok approach from my perspective: We could just change
line 14 of python.eclass and let package maintainers report breakage as
they increment EAPI. I am confident that nothing EAPI <= 3 would break.

Is anyone (especially djc and the python herd members) opposed to this?