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