1 |
On Fri, Aug 31, 2012 at 5:03 AM, Andreas K. Huettel |
2 |
<dilfridge@g.o> wrote: |
3 |
> <rant> |
4 |
> Let's say, we as in Gentoo decide that we're completely sick of keeping all |
5 |
> that old code out there adjusted to newer and newer gcc versions that are more |
6 |
> and more critical towards minor details of the c++ standards. So, we declare |
7 |
> that gcc-4.5 has to be enough for everyone, we'll just keep it in tree forever |
8 |
> and dont bother anymore with all these superfluous "does not build with |
9 |
> gcc-4.7" bugs. |
10 |
|
11 |
That is not an appropriate analogy, as I'm not suggesting that we |
12 |
refuse to support newer EAPIs. I'm just saying that packages |
13 |
shouldn't be bumped just for the sake of bumping them. |
14 |
|
15 |
> |
16 |
> Give me one non-trivial ebuild where you can absolutely guarantee that a bump |
17 |
> from EAPI=0 to EAPI=4 will not enable any improvements (in readability, |
18 |
> failsafe behaviour and code size for example). |
19 |
|
20 |
Suppose for the sake of argument that no such ebuild exists. I still |
21 |
maintain that there is little benefit from forcing an EAPI bump on new |
22 |
ebuilds. |
23 |
|
24 |
If I thought that bumping the EAPI would make my life as a maintainer |
25 |
easier I'd just do it - I wouldn't need a policy to tell me to do it. |
26 |
The only reason you'd need a policy is if I as a maintainer figured |
27 |
that bumping the EAPI was more hassle than whatever benefits I get |
28 |
down the road from all those improvements. |
29 |
|
30 |
If I did think that bumping the EAPI wasn't worth the hassle, and yet |
31 |
I was told that I'd be banned as a dev for not doing so anyway, then |
32 |
obviously I'm going to do the minimum necessary to comply with policy, |
33 |
which means changing the EAPI line of the ebuild and only changing |
34 |
other lines as required to get the thing to build and comply with PMS. |
35 |
So, while all those benefits you named are "enabled" few would |
36 |
actually be realized. |
37 |
|
38 |
> |
39 |
> Last point, if someday the tree contains ebuilds with 7-8 different EAPI's, |
40 |
> we'll have succeeded in generating an unmaintainable mess (tm). It will not be |
41 |
> any fun to look up things in PMS anew everytime you edit something. |
42 |
|
43 |
I suspect that most devs just edit things that they maintain, and that |
44 |
means that they can control how many EAPIs are in use in those |
45 |
ebuilds. Again, devs already have incentive to make their own lives |
46 |
earlier - we don't need to turn that into policy. |
47 |
|
48 |
I might see some benefit for devs who routinely modify stuff that they |
49 |
don't maintain, but that should generally be kept to a minimum anyway. |
50 |
If unsure how how to edit any particular ebuild, just file a bug! |
51 |
And if the package isn't maintained, then nobody will be bumping its |
52 |
EAPI anyway. |
53 |
|
54 |
Rich |