Re: [gentoo-dev] EAPI usage

[Rich Freeman]

On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber <johu@g.o> wrote:
>
> EAPI 0 is more readable than EAPI 4? No benefit for maintainer? No benefit for
> user who wants to read the ebuild? Realy?

Then why make it a policy?

If as you say there is a benefit to the maintainer, then you won't
have to hit them over a head for noncompliance.  Just point out that
newer EAPIs make things easier, and they'll happily use the new EAPIs
if they agree.  If they don't agree, who cares?

You don't need a policy to tell somebody to do something in their own
interest.  The main reason for policy is to get people to do things
that are in the interests of others.

>> The downsides are several - you're taking code that works and fiddling
>> with it, perhaps creating code that doesn't work.  You're forcing that
>> development to take place in the newest EAPI, which is also the
>> version which the everybody has the least experience with (likely less
>> documentation online as well).
>
> devmanual is fine.

I didn't say that the devmanual wasn't fine.  I said that there is
less documentation available online for newer EAPIs.  Documentation
doesn't consist ONLY of the devmanual.  Code examples in the form of
all the other ebuilds in the tree count as well, as do mailing list
posts, forums, blogs, and any of a bazillion other historical records,
which being historical all use older EAPIs.

>
>> Developers have only a limited amount of time, and this will eat into
>> it.  The result is likely to not be new shiny ebuilds that use the new
>> EAPIs, but rather old rusty ones that still use the old EAPI but also
>> which contain other bugs, since they don't get touched at all (since
>> touching them triggers the new policy).
>
> You dont need to touch the old ebuild, but if you are touching it for example
> a version bump, a bug fix etc you should be able to do the EAPI bump as long as
> you have done the ebuild quizzes ;)

The point is that maintainers will be less likely to do the version
bump or the bug fix in the first place, if they have to rewrite half
of the ebuild to do it.

If I have a bug and I can fix one line of an ebuild to fix it, then
I'm much more likely to find the time to do it than if I have to
rewrite half of it.

Also, not everybody maintaining packages has actually done the ebuild
quizzes.  Sure, the person committing the changes has, but we're
trying to get non-developers to contribute as well.  If somebody
submits a patch that works, do we want the dev to just commit it, or
do we want them to say, "sorry, you have to re-write half the ebuild
if you want me to accept that patch?"  Keep in mind that if the dev
had the time to rewrite it themselves they would have likely already
fixed it themselves.

>
> Essential part of software development is refactoring to get the code in a
> modern state.

That only makes sense if you need to make substantial changes to
software, such that the investment in refactoring is going to pay off.
 Few refactor code for its own sake.  However, I am not saying that we
should make it a policy that maintainers NOT be allowed to use newer
EAPIs, but only that it should be up to individual discretion.

Keep in mind that we're not paying developers, and we always have more
work to be done than people to do the work.  In order to make this
work we need to lower barriers to contribution.  If a developer has an
hour to spend on Gentoo, would you rather see them fixing bugs that
actually impact people, or rewriting ebuilds to use newer EAPIs,
possibly creating more bugs that actually impact people.  Keep in mind
that as volunteers devs get to pick what they work on, which means
that they're less motivated to spend that hour doing anything for
Gentoo if it needs to be spent on stuff they don't want to do.

I'm all for enforcing quality rules that actually have an impact on
end users - lots of shoddy work doesn't help anybody.  However, having
rules that don't actually improve things for end users just results in
less work getting done, and in the end a poorer user experience.

Rich