Re: [gentoo-project] Re: Call for agenda items - Council meeting 2013-04-09

["vivo75@gmail.com" <vivo75@gmail.com>]

Il 03/04/2013 11:07, Ralph Sennhauser ha scritto:
> On Tue, 2 Apr 2013 16:31:51 +0100
> Markos Chandras <hwoarang@gentoo.org> wrote:
>
>>> Should we have a stricter rule? Would such a rule help significantly
>>> reducing the number of EAPI 0 ebuilds?  
>> I believe so. Maybe make repoman scream if you commit an ebuild with
>> 1<=EAPI<=4 ?
> I feel strongly against starting with anything but EAPI 0. And I
> don't consider EAPI 4 old enough to start pestering maintainers about
> it.
>
> What we need is a live cycle of EAPIs to keep things manageable in the
> long run. We aren't under pressure to get rid of as many as possible
> ASAP. A simple scheme could be
>
> - EAPI becomes second latest
> - 5 years later repoman warns.
> - 2 years later repoman errors out.
>
> With that scheme EAPI=0  would be due soon. As the "bump to latest
> eapi" policy isn't that old and seems to have only sunk in a about a
> year ago, and the myth of still requiring system packages to be EAPI=0
> kept a lot of the tree at EAPI=0 for a long time. Fact is EAPI 0 ebuilds
> are still many, though the number started to crumble significantly
> lately. So waiting another year before starting actively warn might be
> appropriate.
>
> The important thing is for the council to declare intent and timeframe,
> so maintainers can plan far ahead. The other thing that became apparent
> from last discussion is that a slightly low EAPI shouldn't be a card
> blanch for zealots to touch packages they don't maintain or to file
> bugs about it.
>

Hopefully the council will keep in mind that today it's not possible to
upgrade portage if the system is old enough to require an update from
python-2.6.5-r2 => :2.7, at least not with a lot of trickery with
--nodeps and (much more) equally ugly stuff. python-2.6.5-r2 is dated 01
May 2010 in ChangeLog.

3 years are pratically more than you can ever hope to support without
adding manpower dedicated to keep backward compatibility.

Previous reasoning based on the assumption that a) newer api are better
b) less of them is better c) not being able to upgrade portage mean a
not upgradable/modifiable gentoo install.