EAPI usage
 

> I can't say I'm a big fan of this. This requires forcing changes to
> ebuilds that offer no actual benefit to either the maintainer or the
> end-users (changes that actually have some benefit to either are
> likely to be made anyway). The PM maintainers have chimed in that
> there is no benefit to PM maintenance from this change.

EAPI 0 is more readable than EAPI 4? No benefit for maintainer? No benefit for
user who wants to read the ebuild? Realy?

> So, I can't really see what the upside of such a policy is.
>
> 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.

> 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 ;)

> For a real-world analogy - look at the result of well-intended laws
> that require ADA compliance and such on building modifications. The
> result is often stuff like kids taking classes in modular trailers and
> such because in order to add an extension to the building you need to
> bring the entire building up to code (and not just the new part). The
> result isn't more elevators and ramps - but the use of hacked together
> solutions to work around the policy.

Examples?

> If it ain't broke, don't fix it.

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

> Now, if a maintainer actually needs a feature of a new EAPI, or an
> ebuild contains a bug that can only be addressed by bumping it, then
> by all means the maintainer should be revising the ebuild. Then there
> is actually an upside to balance the cost.

True.

> Rich

Greetings,
--
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

EAPI usage
 

> Could you elaborate what the reasons FOR it are (not that I don't know
> any, but you brought it up) since this will add work for every developer
> to check a) how the behavior of the new EAPI impacts the current ebuild
> and b) how the behvaior of inherited eclasses change depending on EAPI.

My main arguement is a modern code base, my intention is not to touch the
ebuild if there is no reason. But if you are doing a version bump, bug fix etc
you working on the package anyway.

a) thats normal developer work
b) if there is a bug in the eclass for a specified EAPI you should file a bug

--
Johannes Huber (johu)
Gentoo Linux Developer / KDE Team
GPG Key ID F3CFD2BD

EAPI usage
 

On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber <johu@gentoo.org> 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

EAPI usage
 

On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber <johu@gentoo.org> wrote:

[snip]

>> 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 ;)

I'm a proxy maintainer. Meaning I haven't done these quizzes. Heck,
I've never even seen them. I catch bug reports, come up with a
solution and pass it back to Markos, who then decides whether or not
to put it in and give feedback.

How would this impact me?

>
>> For a real-world analogy - look at the result of well-intended laws
>> that require ADA compliance and such on building modifications. The
>> result is often stuff like kids taking classes in modular trailers and
>> such because in order to add an extension to the building you need to
>> bring the entire building up to code (and not just the new part). The
>> result isn't more elevators and ramps - but the use of hacked together
>> solutions to work around the policy.
>
> Examples?

Every single hack you've ever seen which was written to get a unit
test to pass, but makes the code more difficult to modify or refactor
in the future.

>
>> If it ain't broke, don't fix it.
>
> Essential part of software development is refactoring to get the code in a
> modern state.

As a professional software developer, I can say that the decision to
refactor or not is couched deeply in the question of whether or not it
makes sense to do it at that moment. Typically, you don't refactor
unless time pressures are sufficiently low, or unless you can see some
specific way that the refactor will save you time in the very near
future.

The latter condition will happen normally for a maintainer. But all
maintainers are volunteers, which means time pressures are always
high. (Especially if they have lives outside of Gentoo.)

--
:wq

EAPI usage
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/08/12 08:37 AM, Michael Mol wrote:
> On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber <johu@gentoo.org>
> wrote:
>
> [snip]
>
>>> 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 ;)
>
> I'm a proxy maintainer. Meaning I haven't done these quizzes.
> Heck, I've never even seen them. I catch bug reports, come up with
> a solution and pass it back to Markos, who then decides whether or
> not to put it in and give feedback.
>
> How would this impact me?
>

If you are rewriting a full ebuild as your solution, and the ebuild
you start with is EAPI<4 , then Markos would appreciate it if you
changed the ebuild to be EAPI=4 (or whatever the latest EAPI is) in
addition to the fix. Otherwise, just do what you do and Markos
"should" bump the ebuild to EAPI=4 when he applies your fixes.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlA/Y1gACgkQ2ugaI38ACPCq1wEAowuUqEMzAj1vFXFrE0fkOkEi
gt4rKXXuCCxgb0h11WABAKsMa/7OI2dqX/JA6eXSYOAfsdm5vI7IUCY4MirLlT6s
=jwzi
-----END PGP SIGNATURE-----

EAPI usage
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/08/12 08:30 AM, Rich Freeman wrote:
> On Thu, Aug 30, 2012 at 7:29 AM, Johannes Huber <johu@gentoo.org>
> 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?
>

("Realy?" in the above specifies the statement was sarcastic)

> 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 primary benefit to the policy that dev's should bump EAPI when
bumping ebuilds is so that older inferior EAPIs can be deprecated and
eventually removed from the tree.

Take, for example, the sub-slot and slot-operator support that will
hopefully be applied as part of EAPI=5 -- when this is integrated
across the tree, there will be little to no purpose for revdep-rebuild
and/or @preserved-libs. But this tree-wide integration would never
happen if said policy didn't exist, ie, I think this is a good example
of "interests of others".

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlA/ZNEACgkQ2ugaI38ACPAthAD/XDwdxGj/cDprcFUtPUtklPaU
6KbooOamqxFJrfVxMbgBAJ56bQ+TYrYQ+eSvV+38bknCsp1+bK WfwXa1GxSERJha
=iaCP
-----END PGP SIGNATURE-----

EAPI usage
 

On Thu, Aug 30, 2012 at 8:58 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
> If you are rewriting a full ebuild as your solution, and the ebuild
> you start with is EAPI<4 , then Markos would appreciate it if you
> changed the ebuild to be EAPI=4 (or whatever the latest EAPI is) in
> addition to the fix. Otherwise, just do what you do and Markos
> "should" bump the ebuild to EAPI=4 when he applies your fixes.

And if he doesn't have time to do that, he'll just go ahead and ignore
your bug and users can make do without the fix. :)

Rich

EAPI usage
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 30/08/12 09:04 AM, Rich Freeman wrote:
> On Thu, Aug 30, 2012 at 8:58 AM, Ian Stakenvicius <axs@gentoo.org>
> wrote:
>> If you are rewriting a full ebuild as your solution, and the
>> ebuild you start with is EAPI<4 , then Markos would appreciate it
>> if you changed the ebuild to be EAPI=4 (or whatever the latest
>> EAPI is) in addition to the fix. Otherwise, just do what you do
>> and Markos "should" bump the ebuild to EAPI=4 when he applies
>> your fixes.
>
> And if he doesn't have time to do that, he'll just go ahead and
> ignore your bug and users can make do without the fix. :)
>
> Rich
>

I think you may miss the meaning of "should". It's not the same as
"must". IE, when bug or security fixes happen, i'm pretty sure it's
still OK to apply those (even when bumping the ebuild) as soon as
possible even though the ebuild isn't EAPI=4.

The idea here is to not let old EAPI's sit around in the tree forever,
not to halt all maintenance.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)

iF4EAREIAAYFAlA/ZX8ACgkQ2ugaI38ACPCUWQD/azjLKkv6Mpa1tLuupSuOM5AZ
O1y83kdzWAYqeU/4tZAA/i/+8kEhOf76UDxm3f8K1AhOxQp7GUg/mO2MBRStdln+
=hM58
-----END PGP SIGNATURE-----

EAPI usage
 

On Thu, Aug 30, 2012 at 9:04 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
>
> The primary benefit to the policy that dev's should bump EAPI when
> bumping ebuilds is so that older inferior EAPIs can be deprecated and
> eventually removed from the tree.

What is the benefit from removing the old EAPIs?

>
> Take, for example, the sub-slot and slot-operator support that will
> hopefully be applied as part of EAPI=5 -- when this is integrated
> across the tree, there will be little to no purpose for revdep-rebuild
> and/or @preserved-libs. But this tree-wide integration would never
> happen if said policy didn't exist, ie, I think this is a good example
> of "interests of others".

Then ask nicely for everybody to implement these features, and make it
a policy if necessary.

Simply bumping an ebuild to EAPI=5 doesn't even guarantee that either
of those features would be used anyway.

If there is a benefit from some specific practice, then let's adopt
it. However, I don't think that is the same as just bumping EAPIs for
their own sake.

When there is a benefit to adopting a new EAPI of course maintainers
should try to take advantage of it. If there are specific changes we
want to try to make tree-wide let's try to do that too. But, why bump
ebuilds from 0 to 1 to 2 to 3 to 4 to 5 when your only example of an
end-user benefit would have been achieved if we just bumped from 0 to
5 in one step?

Rich

EAPI usage
 

On Thu, Aug 30, 2012 at 9:07 AM, Ian Stakenvicius <axs@gentoo.org> wrote:
> I think you may miss the meaning of "should". It's not the same as
> "must".

Is it a policy or not? If it is a policy we can ignore at our own
discretion, then by all means pass it, and we can all do whatever we
like, as we already are. :)

Rich