1 |
On Tue, Mar 4, 2014 at 3:13 AM, Ulrich Mueller <ulm@g.o> wrote: |
2 |
> If changing ebuilds to a banned EAPI is allowed, then we can as well |
3 |
> lift the ban altogether: I could create a new ebuild under some |
4 |
> allowed EAPI, then change it to a banned one, and it would still be |
5 |
> within the rules. |
6 |
|
7 |
In this case it was changed from 0 to 1. I could see this argument if |
8 |
it was changed from 5 to 1. This also wasn't some attempt to find |
9 |
loopholes in the rules. If it were I'd recommend issuing a clear |
10 |
declaration that the developer followed all the rules to the letter |
11 |
and then punishing them for it anyway to make an example out of them. |
12 |
If we're going to rely exclusively on rules to prevent antisocial |
13 |
behavior I can guarantee that we're going to fail miserably, kind of |
14 |
like the mortgage market in 2008. Intent matters far more than |
15 |
compliance. |
16 |
|
17 |
Some EAPI changes are easier than others. This one was only from |
18 |
non-banned to banned because we haven't gotten around to banning EAPI |
19 |
0 yet. I'm all for doing that for non-toolchain ebuilds until we |
20 |
figure out what to do with the toolchain. |
21 |
|
22 |
There also isn't any deadline I can see for getting rid of EAPI |
23 |
1/2/etc. We're just trying to speed the process up so that it doesn't |
24 |
take a decade (which is basically the current trend). |
25 |
|
26 |
I guess I just don't see this as something likely to become a major |
27 |
problem. If it becomes one we can deal with it. |
28 |
|
29 |
Don't get me wrong - I'm fine with clarifying rules/etc. I just want |
30 |
to avoid chasing after the perfect set of rules, because they'll never |
31 |
be perfect, and that really isn't the source of problems in a |
32 |
community. |
33 |
|
34 |
Rich |