| 1 |
On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius <axs@g.o> wrote: |
| 2 |
> |
| 3 |
> The primary benefit to the policy that dev's should bump EAPI when |
| 4 |
> bumping ebuilds is so that older inferior EAPIs can be deprecated and |
| 5 |
> eventually removed from the tree. |
| 6 |
|
| 7 |
What is the benefit from removing the old EAPIs? |
| 8 |
|
| 9 |
> |
| 10 |
> Take, for example, the sub-slot and slot-operator support that will |
| 11 |
> hopefully be applied as part of EAPI=5 -- when this is integrated |
| 12 |
> across the tree, there will be little to no purpose for revdep-rebuild |
| 13 |
> and/or @preserved-libs. But this tree-wide integration would never |
| 14 |
> happen if said policy didn't exist, ie, I think this is a good example |
| 15 |
> of "interests of others". |
| 16 |
|
| 17 |
Then ask nicely for everybody to implement these features, and make it |
| 18 |
a policy if necessary. |
| 19 |
|
| 20 |
Simply bumping an ebuild to EAPI=5 doesn't even guarantee that either |
| 21 |
of those features would be used anyway. |
| 22 |
|
| 23 |
If there is a benefit from some specific practice, then let's adopt |
| 24 |
it. However, I don't think that is the same as just bumping EAPIs for |
| 25 |
their own sake. |
| 26 |
|
| 27 |
When there is a benefit to adopting a new EAPI of course maintainers |
| 28 |
should try to take advantage of it. If there are specific changes we |
| 29 |
want to try to make tree-wide let's try to do that too. But, why bump |
| 30 |
ebuilds from 0 to 1 to 2 to 3 to 4 to 5 when your only example of an |
| 31 |
end-user benefit would have been achieved if we just bumped from 0 to |
| 32 |
5 in one step? |
| 33 |
|
| 34 |
Rich |
Archives