[gentoo-dev] EAPI usage

[gentoo-dev] EAPI usage

[Johannes Huber]

Hello gentoo devs,

From last council meeting summary:
[snip]
> Open floor
> ==========
> scarabeus suggested the change "dev should use latest eapi when bumping"
> to "dev must use latest eapi when bumping if not forbidden by eclasses".
> He was asked to bring it up on the mailing lists, to get a better
> definition of when what EAPI should be used.
[/snip]

I raised the issue through scarabeus, as in my opinion there is no reason to 
not use latest EAPI. So please discuss.

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

Re: [gentoo-dev] EAPI usage

[Rich Freeman]

On Thu, Aug 30, 2012 at 6:28 AM, Johannes Huber <johu@gentoo.org> wrote:
>> scarabeus suggested the change "dev should use latest eapi when bumping"
>> to "dev must use latest eapi when bumping if not forbidden by eclasses".
>> He was asked to bring it up on the mailing lists, to get a better
>> definition of when what EAPI should be used.
>
> I raised the issue through scarabeus, as in my opinion there is no reason to
> not use latest EAPI. So please discuss.
>

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.

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

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

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.

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

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.

Rich

Re: [gentoo-dev] EAPI usage

[Johannes Huber]

> 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

Re: [gentoo-dev] EAPI usage

[Rich Freeman]

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

Re: [gentoo-dev] EAPI usage

[Ian Stakenvicius]

-----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+bKWfwXa1GxSERJha
=iaCP
-----END PGP SIGNATURE-----

Re: [gentoo-dev] EAPI usage

[Rich Freeman]

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

Re: [gentoo-dev] EAPI usage

[Michael Mol]

On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman <rich0@gentoo.org> wrote:
> 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?

I can answer this one...removing old EAPIs simplifies code for things
which need to be EAPI-aware. There are no bugs in code that doesn't
exist.

-- 
:wq

Re: [gentoo-dev] EAPI usage

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

Michael Mol schrieb:
> On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman <rich0@gentoo.org> wrote:
>> 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?
> 
> I can answer this one...removing old EAPIs simplifies code for things
> which need to be EAPI-aware. There are no bugs in code that doesn't
> exist.
> 

Like package managers?

Sorry, but this is not true, since you can never assume, that older
EAPIs dont exist any more (even a simple EAPI-0 ebuild, which never
needed a bump, is enough), so older EAPI versions have to be supported
forever.

-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 380 bytes --]

Re: [gentoo-dev] EAPI usage

[Michael Mol]

On Thu, Aug 30, 2012 at 3:47 PM, Thomas Sachau <tommy@gentoo.org> wrote:
> Michael Mol schrieb:
>> On Thu, Aug 30, 2012 at 9:14 AM, Rich Freeman <rich0@gentoo.org> wrote:
>>> 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?
>>
>> I can answer this one...removing old EAPIs simplifies code for things
>> which need to be EAPI-aware. There are no bugs in code that doesn't
>> exist.
>>
>
> Like package managers?
>
> Sorry, but this is not true, since you can never assume, that older
> EAPIs dont exist any more (even a simple EAPI-0 ebuild, which never
> needed a bump, is enough), so older EAPI versions have to be supported
> forever.

I would assume that's what auditing is for. Unless I'm sorely mistaken
(and I may be; I don't know much at all about eclasses), it should be
fairly simple to script through the tree to find any eclasses or
ebuilds which express a dependency on an EAPI of a given level,
presuming the expression is of a standard form.

Compile a list of existing ebuilds which depend on old EAPIs, and
you've got a TODO list. (eclasses, I don't know; I don't know if
eclasses explicitly express EAPI compatibility in metadata) Once that
list is cleared, yes, you can assume there are no ebuilds with a
specified EAPI of 0. I'd presume it would have been made widely known
that new ebuilds shouldn't use the old EAPI by that point, and so
support for the deprecated EAPI level can be abandoned.

Out-of-tree ebuilds pose their own problems, but that's a matter for
the managers of the relevant overlays.

Now, for the million-dollar question: Who should do the work? My
answer would be "whoever wants it done." Whoever wants the work done
can go through their audit list and submit the relevant patches to the
maintainers. Whether that's a team of twenty people or the work of an
individual with a shell script and a lot of time on his hands, that's
where that kind of work belongs. Now, if a maintainer rejects the
patch, then the submitter can fix the patch to the maintainer's
specifications. If the maintainer rejects the patch on some principle,
that's an issue that can be raised and dealt with rationally at the
time it happens. I imagine most maintainers would welcome assistance,
especially if it means simplifying future work they may need to do.

-- 
:wq

Re: [gentoo-dev] EAPI usage

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 715 bytes --]

On Thu, 30 Aug 2012 16:05:52 -0400
Michael Mol <mikemol@gmail.com> wrote:
> Compile a list of existing ebuilds which depend on old EAPIs, and
> you've got a TODO list. (eclasses, I don't know; I don't know if
> eclasses explicitly express EAPI compatibility in metadata) Once that
> list is cleared, yes, you can assume there are no ebuilds with a
> specified EAPI of 0. I'd presume it would have been made widely known
> that new ebuilds shouldn't use the old EAPI by that point, and so
> support for the deprecated EAPI level can be abandoned.

You can't uninstall a package if you don't support its EAPI.

The "remove code" benefit applies to eclasses, not package manglers.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

[gentoo-dev] Re: EAPI usage

[Duncan]

Ciaran McCreesh posted on Thu, 30 Aug 2012 21:11:02 +0100 as excerpted:

> On Thu, 30 Aug 2012 16:05:52 -0400 Michael Mol <mikemol@gmail.com>
> wrote:
>> Compile a list of existing ebuilds which depend on old EAPIs, and
>> you've got a TODO list. (eclasses, I don't know; I don't know if
>> eclasses explicitly express EAPI compatibility in metadata) Once that
>> list is cleared, yes, you can assume there are no ebuilds with a
>> specified EAPI of 0. I'd presume it would have been made widely known
>> that new ebuilds shouldn't use the old EAPI by that point, and so
>> support for the deprecated EAPI level can be abandoned.
> 
> You can't uninstall a package if you don't support its EAPI.
> 
> The "remove code" benefit applies to eclasses, not package manglers.

I've seen that reason given before, and it makes sense... to a point.

Would this work, tho?

In addition to the tree clean of EAPI-X to be dropped...

Some minimum time/versions (say six months) before a PM drops support for 
it, on PM upgrades it starts warning about the coming drop of EAPI-X 
support, giving the user a reasonable deadline (the same six months) to 
upgrade or uninstall said packages as PM versions after that date will be 
dropping support.

Then at a shorter deadline (say two months), start warning at each PM 
invocation.

When the upgrade that will drop support appears, if any packages of now 
unsupported EAPI-X remain installed, it simply dies with a warning that 
upgrading isn't possible as unsupported packages remain installed, 
instructing the user to upgrade or unmerge them first, before upgrading 
the PM.

By this time, the tree would have been clean of EAPI-X for the longer 
deadline (six months in this example), and the warning will have appeared 
on PM upgrade for the same period and on every PM invocation for the 
shorter period (two months here), so people doing anything close to 
regular upgrades will have long since upgraded past or unmerged whatever 
lagging packages they had merged.

For the people that do NOT upgrade frequently, the die before PM upgrade 
will force the issue, if/when they DO decide to upgrade.

Covering the case where the troublesome packages themselves have moved on 
beyond something the installed PM can handle, it's still possible to 
unmerge the package temporarily, then merge it again after they upgrade.

(If thought necessary, the usual I_KNOW_WHAT_IM_DOING override could be 
inserted, but in this case I think simply having them unmerge the 
packages in question is the safer alternative.  After all, it's only 
going to hit the folks who are SO far out of date that there's no 
bridging package version available, for the offending package.)

Of course there'd need to be special consideration given to critical 
toolchain and system boot packages, but /that's/ nothing new.

And as has always been the case, for the /extreme/ laggards, at some 
point, say two years out or whatever, simply don't support upgrading that 
far any more, with a clean install from stage-3 being the recommended 
alternative.

Of course an individual PM could choose to keep support for as long as 
they want, but unless I'm missing something, that'd let PMs drop support 
for old EAPIs if desired, with at least a reasonably sane upgrade path 
for both PM devs and users.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: EAPI usage

[Rich Freeman]

On Thu, Aug 30, 2012 at 7:58 PM, Duncan <1i5t5.duncan@cox.net> wrote:
> Ciaran McCreesh posted on Thu, 30 Aug 2012 21:11:02 +0100 as excerpted:
> Some minimum time/versions (say six months) before a PM drops support for
> it, on PM upgrades it starts warning about the coming drop of EAPI-X
> support, giving the user a reasonable deadline (the same six months) to
> upgrade or uninstall said packages as PM versions after that date will be
> dropping support.

I actually don't have a problem with this.  If there were a
coordinated effort to completely deprecate an EAPI and the PM teams
vouched that it would make their life easier, I'd be happy to be a
part of a concerted effort to bump everything to where it needs to be.
 If we made the transition long then it would be mostly transparent to
users.  If they had some odd package still installed with an old EAPI
they could always re-install it to clean up the installed package
database.

My main concern is doing bumps all the time just for their own sake.

Rich

[gentoo-dev] Re: EAPI usage

[Duncan]

Rich Freeman posted on Thu, 30 Aug 2012 20:38:11 -0400 as excerpted:

> My main concern is doing bumps all the time just for their own sake.

Yes.  That's why I didn't tackle that side at all.  But I've seen the 
"PM's can never drop support for an EAPI once adopted" thing before, and 
while there's quite a possibility I'm missing something as I'm no PM 
expert, it does seem to me that rings hollow; that an EAPI drop COULD be 
done, without too much disrupting either users or devs (PM or otherwise).

But as the experts say otherwise, there probably /is/ something I'm 
missing, which is why I asked.

Meanwhile, I'll definitely allow that there's often a big chasm between 
"possible" and "worth the trouble", too, and it's quite within the realm 
of reason that it's simply "not worth the trouble" at this point, even if 
very much possible, and even likely worth the trouble once we get upto 
say 10 EAPIs or some such.

Meanwhile(2), I (cautiously) support the idea I've seen before of 
deprecating and gradually removing at least EAPI-1, and probably 2 and 3 
as well over time.  People /have/ pointed out that core system packages, 
toolchain, etc, may well need to stay at EAPI-0 virtually "forever".  
That's the exception I mentioned with EAPI-0 thus being an exception as 
well, thus the focus on 1-3.  But once 1-3 are out of the tree for a 
sufficient period, I really /don't/ see why the method I described can't 
be used to drop their support from the PMs, as well, and expect that 
regardless of whether it's worth tackling as a project starting today, at 
some point, it'll be worth doing.

OTOH, I can see someone, possibly concerned about the historical 
implications (so "gentoo historians" at least, can try long deprecated 
ebuilds and see how they work), might wish to maintain support for every 
EAPI "forever".  But I don't believe it should be mandatory, and in 
practice, I'd venture that due to simple code rot once there haven't been 
any packages of a particular EAPI in the tree or in wide circulation for 
awhile, even if support /does/ officially continue, it'll likely be 
broken if anyone tries to use it, say five years or a decade later.  Once 
that starts being a major concern, why /not/ just dump it.  The 
historians can go find an old stage tarball with an old PM that supported 
the EAPIs they're interested in, if it comes to that.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: EAPI usage

[Zac Medico]

On 08/30/2012 08:33 PM, Duncan wrote:
> Rich Freeman posted on Thu, 30 Aug 2012 20:38:11 -0400 as excerpted:
> 
>> My main concern is doing bumps all the time just for their own sake.
> 
> Yes.  That's why I didn't tackle that side at all.  But I've seen the 
> "PM's can never drop support for an EAPI once adopted" thing before, and 
> while there's quite a possibility I'm missing something as I'm no PM 
> expert, it does seem to me that rings hollow; that an EAPI drop COULD be 
> done, without too much disrupting either users or devs (PM or otherwise).
> 
> But as the experts say otherwise, there probably /is/ something I'm 
> missing, which is why I asked.

It would be a bad idea to remove support for *uninstalling* an ebuild
with a given EAPI, since any given system that the PM encounters could
potentially have ebuilds with any old EAPI installed. OTOH, removing
support for *installing* a given EAPI is quite feasible.

In Portage, we occasionally deprecate EAPIs that only existed for the
purpose of testing. Once an EAPI is deprecated, ebuilds using that EAPI
can no longer be installed, but they can still be uninstalled (including
execution of pkg_prerm/pkg_postrm phases).

That said, deprecation of official EAPIs such as EAPI 0, 1, and 2 would
not lead to much code being removed, because the later EAPIs share so
much code with them. So, deprecating official EAPIs provides little or
no benefit in terms of code maintenance.
-- 
Thanks,
Zac

Re: [gentoo-dev] Re: EAPI usage

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 834 bytes --]

On Thu, 30 Aug 2012 23:58:00 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:
> Of course an individual PM could choose to keep support for as long
> as they want, but unless I'm missing something, that'd let PMs drop
> support for old EAPIs if desired, with at least a reasonably sane
> upgrade path for both PM devs and users.

It's irrelevant: the amount of package mangler code to be saved by
removing old EAPIs is so small it's not worth discussing. Most EAPI
changes so far have either been additions or very simple behaviour
tweaks, not removals of annoying things.

There are things we might change in future EAPIs that will in the very
long term make this discussion worthwhile. If we get rid of VDB access
or unconstrained env saving, *then* it might be worth having this
discussion.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] Re: EAPI usage

[Brian Harring]

On Fri, Aug 31, 2012 at 03:49:43PM +0100, Ciaran McCreesh wrote:
> On Thu, 30 Aug 2012 23:58:00 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
> > Of course an individual PM could choose to keep support for as long
> > as they want, but unless I'm missing something, that'd let PMs drop
> > support for old EAPIs if desired, with at least a reasonably sane
> > upgrade path for both PM devs and users.
> 
> It's irrelevant: the amount of package mangler code to be saved by
> removing old EAPIs is so small it's not worth discussing. Most EAPI
> changes so far have either been additions or very simple behaviour
> tweaks, not removals of annoying things.

Just seconding this statement; no PM author has stated "maintaining 
EAPIs is an undue burden"- it's come everytime from folks who don't 
/actually do any PM code/.

So please stop telling us what is, and isn't a burden in our code. :)


> There are things we might change in future EAPIs that will in the very
> long term make this discussion worthwhile. If we get rid of VDB access
> or unconstrained env saving, *then* it might be worth having this
> discussion.

Realistically even then, that's just swivelling vars/functions exposed 
to the ebuild env- it would require the vast majority of ebuilds 
migrating to EAPI versions that hide VDB access for this to be worth 
discussing (else due to backwards compat, it's a pointless 
discussion).


Either way, there's no reason to require devs use the latest EAPI; 
they migrate at their own pace as they need to, which is fine.  Case 
in point, check gentoo-x86 eapi usage:

repository '/var/db/repos/gentoo':
  eapi: '4' 13523 pkgs found, 42.58% of the repository
  eapi: '0' 8171 pkgs found, 25.73% of the repository
  eapi: '2' 5246 pkgs found, 16.52% of the repository
  eapi: '3' 4297 pkgs found, 13.53% of the repository
  eapi: '1' 520 pkgs found, 1.64% of the repository

0 is still in heavy usage since a lot of ebuilds don't need the newer 
EAPI functionality; 1 is mostly dead since the only gain of it (in 
comparison to 0) was slot deps, 2 had used use deps thus those same 
folk migrated to 2 (since if you need slot deps, it's semi likely you 
need use deps).

As for 3... that was prefix and xz support.  No reason to use it in 
comparison to 4 frankly.

Personally, I don't have any problems if gentoo were to mandate that 
EAPI1 shouldn't be used for new ebuilds in gentoo-x86, eapi2 instead.  
That sort of standard would make sense.

~harring

Re: [gentoo-dev] EAPI usage

[Ian Stakenvicius]

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

On 30/08/12 09:14 AM, Rich Freeman wrote:
> 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?

Simpler eclasses is the first thing that comes to mind.  Consistency
in the way the dependency tree is built would be another (when newer
EAPIs address such things, that is)

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

..although this could technicaly be true, I think most developers
would assume that bumping EAPI doesn't mean changing the EAPI variable
from whatever to 5 and that's it; the "bump" should involve
integrating any applicable features that the new EAPI offers.

> 
> 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?


We used to have a policy that the oldest EAPI that implements all
features needed for an ebuild is the one that should be used.  Now (as
of when EAPI=4 was made official i think?) it's the reverse -- the
newest (official) EAPI is the one that should be used.  All this
policy change suggestion scarabeus provided is doing, is recommending
that developers bump EAPI when they bump their ebuilds, as compared to
only when writing new ones (which is all the current policy would
require us to do).

if you want another example, i'm sure end-user benefits would have
ensued if many existing packages that die in pkg_setup were bumped to
EAPI=4 right away and their checks moved to pkg_pretend.  Examples
prior to EAPI=4 are irrelevent as the policy was different then.

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

iF4EAREIAAYFAlA/a6sACgkQ2ugaI38ACPBO5wD+JSBmTT3j0MFc1GMjIDatRLnV
J7Oj3rQWjS3GKpU8pQgBALsVg7R1QGGjETv0KS3j9yxBlflr4PlKECboVXqoRupL
=+zxo
-----END PGP SIGNATURE-----

Re: [gentoo-dev] EAPI usage

[Michael Mol]

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

Re: [gentoo-dev] EAPI usage

[Ian Stakenvicius]

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

Re: [gentoo-dev] EAPI usage

[Rich Freeman]

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

Re: [gentoo-dev] EAPI usage

[Ian Stakenvicius]

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

Re: [gentoo-dev] EAPI usage

[Rich Freeman]

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

Re: [gentoo-dev] EAPI usage

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 3095 bytes --]

Am Donnerstag, 30. August 2012, 12:57:25 schrieb Rich Freeman:
> On Thu, Aug 30, 2012 at 6:28 AM, Johannes Huber <johu@gentoo.org> wrote:
> >> scarabeus suggested the change "dev should use latest eapi when bumping"
> >> to "dev must use latest eapi when bumping if not forbidden by eclasses".
> >> He was asked to bring it up on the mailing lists, to get a better
> >> definition of when what EAPI should be used.
> > 
> > I raised the issue through scarabeus, as in my opinion there is no reason
> > to not use latest EAPI. So please discuss.
> 
> 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.
> 
> So, I can't really see what the upside of such a policy is.
> 

<rant>
Let's say, we as in Gentoo decide that we're completely sick of keeping all 
that old code out there adjusted to newer and newer gcc versions that are more 
and more critical towards minor details of the c++ standards. So, we declare 
that gcc-4.5 has to be enough for everyone, we'll just keep it in tree forever 
and dont bother anymore with all these superfluous "does not build with 
gcc-4.7" bugs. 

Well, newer gcc versions might have some very minor marginal advantages, but 
they require that we mess with code that has worked for ages. They require 
that we actually give some thought on the evolution of the language semantics 
or nag upstream, but we can't really be bothered with that because of limited 
time. Also, keeping gcc-4.5 will always (trivially) keep us backward 
compatibility... much more important than forward compatibility, should 
porting to a much never future version ever become necessary.

For a real world analogy, serious quakes happen only once a century... why 
should we even bother with improving building codes? I mean, at some point in 
the future things will fall apart anyway. Better dont shake anything in 
between.
</rant>

Sorry but I could not really resist... please take it with a grain of salt. 
However, seriously, ...

Give me one non-trivial ebuild where you can absolutely guarantee that a bump 
from EAPI=0 to EAPI=4 will not enable any improvements (in readability, 
failsafe behaviour and code size for example).

Last point, if someday the tree contains ebuilds with 7-8 different EAPI's, 
we'll have succeeded in generating an unmaintainable mess (tm). It will not be 
any fun to look up things in PMS anew everytime you edit something. (Was the 
prayer to Paludis only required in EAPI=7 in src_prepare or in EAPI=8 in 
pkg_preinst?) This problem could however also be solved by selectively phasing 
out in-between EAPIs (i.e. deprecate EAPIs 1 and 3 asap).

Cheers, 
Andreas

-- 
Andreas K. Huettel
Gentoo Linux developer 
kde (team lead), sci, tex, arm, printing
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] EAPI usage

[Fabian Groffen]

[-- Attachment #1: Type: text/plain, Size: 443 bytes --]

On 31-08-2012 11:03:06 +0200, Andreas K. Huettel wrote:
> any fun to look up things in PMS anew everytime you edit something. (Was the 
> prayer to Paludis only required in EAPI=7 in src_prepare or in EAPI=8 in 
> pkg_preinst?) This problem could however also be solved by selectively phasing 
> out in-between EAPIs (i.e. deprecate EAPIs 1 and 3 asap).

I guess you meant 1 and 2.


-- 
Fabian Groffen
Gentoo on a different level

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] EAPI usage

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 686 bytes --]

Am Freitag, 31. August 2012, 11:11:37 schrieb Fabian Groffen:
> On 31-08-2012 11:03:06 +0200, Andreas K. Huettel wrote:
> > any fun to look up things in PMS anew everytime you edit something. (Was
> > the prayer to Paludis only required in EAPI=7 in src_prepare or in
> > EAPI=8 in pkg_preinst?) This problem could however also be solved by
> > selectively phasing out in-between EAPIs (i.e. deprecate EAPIs 1 and 3
> > asap).
> 
> I guess you meant 1 and 2.

Actually I dont care... but 2 could certainly go faster than 3, true. :)

-- 
Andreas K. Huettel
Gentoo Linux developer 
kde (team lead), sci, tex, arm, printing
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] EAPI usage

[Johannes Huber]

Am Freitag, 31. August 2012, 11:03:06 schrieb Andreas K. Huettel:
> Am Donnerstag, 30. August 2012, 12:57:25 schrieb Rich Freeman:
> > On Thu, Aug 30, 2012 at 6:28 AM, Johannes Huber <johu@gentoo.org> wrote:
> > >> scarabeus suggested the change "dev should use latest eapi when
> > >> bumping"
> > >> to "dev must use latest eapi when bumping if not forbidden by
> > >> eclasses".
> > >> He was asked to bring it up on the mailing lists, to get a better
> > >> definition of when what EAPI should be used.
> > > 
> > > I raised the issue through scarabeus, as in my opinion there is no
> > > reason
> > > to not use latest EAPI. So please discuss.
> > 
> > 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.
> > 
> > So, I can't really see what the upside of such a policy is.
> 
> <rant>
> Let's say, we as in Gentoo decide that we're completely sick of keeping all
> that old code out there adjusted to newer and newer gcc versions that are
> more and more critical towards minor details of the c++ standards. So, we
> declare that gcc-4.5 has to be enough for everyone, we'll just keep it in
> tree forever and dont bother anymore with all these superfluous "does not
> build with gcc-4.7" bugs.
> 
> Well, newer gcc versions might have some very minor marginal advantages, but
> they require that we mess with code that has worked for ages. They require
> that we actually give some thought on the evolution of the language
> semantics or nag upstream, but we can't really be bothered with that
> because of limited time. Also, keeping gcc-4.5 will always (trivially) keep
> us backward compatibility... much more important than forward
> compatibility, should porting to a much never future version ever become
> necessary.
> 
> For a real world analogy, serious quakes happen only once a century... why
> should we even bother with improving building codes? I mean, at some point
> in the future things will fall apart anyway. Better dont shake anything in
> between.
> </rant>
> 
> Sorry but I could not really resist... please take it with a grain of salt.
> However, seriously, ...
> 
> Give me one non-trivial ebuild where you can absolutely guarantee that a
> bump from EAPI=0 to EAPI=4 will not enable any improvements (in
> readability, failsafe behaviour and code size for example).
> 
> Last point, if someday the tree contains ebuilds with 7-8 different EAPI's,
> we'll have succeeded in generating an unmaintainable mess (tm). It will not
> be any fun to look up things in PMS anew everytime you edit something. (Was
> the prayer to Paludis only required in EAPI=7 in src_prepare or in EAPI=8
> in pkg_preinst?) This problem could however also be solved by selectively
> phasing out in-between EAPIs (i.e. deprecate EAPIs 1 and 3 asap).

Words of wisdom, nothing to add.

Greetings.

> Cheers,
> Andreas

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

Re: [gentoo-dev] EAPI usage

[Rich Freeman]

On Fri, Aug 31, 2012 at 5:03 AM, Andreas K. Huettel
<dilfridge@gentoo.org> wrote:
> <rant>
> Let's say, we as in Gentoo decide that we're completely sick of keeping all
> that old code out there adjusted to newer and newer gcc versions that are more
> and more critical towards minor details of the c++ standards. So, we declare
> that gcc-4.5 has to be enough for everyone, we'll just keep it in tree forever
> and dont bother anymore with all these superfluous "does not build with
> gcc-4.7" bugs.

That is not an appropriate analogy, as I'm not suggesting that we
refuse to support newer EAPIs.  I'm just saying that packages
shouldn't be bumped just for the sake of bumping them.

>
> Give me one non-trivial ebuild where you can absolutely guarantee that a bump
> from EAPI=0 to EAPI=4 will not enable any improvements (in readability,
> failsafe behaviour and code size for example).

Suppose for the sake of argument that no such ebuild exists.  I still
maintain that there is little benefit from forcing an EAPI bump on new
ebuilds.

If I thought that bumping the EAPI would make my life as a maintainer
easier I'd just do it - I wouldn't need a policy to tell me to do it.
The only reason you'd need a policy is if I as a maintainer figured
that bumping the EAPI was more hassle than whatever benefits I get
down the road from all those improvements.

If I did think that bumping the EAPI wasn't worth the hassle, and yet
I was told that I'd be banned as a dev for not doing so anyway, then
obviously I'm going to do the minimum necessary to comply with policy,
which means changing the EAPI line of the ebuild and only changing
other lines as required to get the thing to build and comply with PMS.
 So, while all those benefits you named are "enabled" few would
actually be realized.

>
> Last point, if someday the tree contains ebuilds with 7-8 different EAPI's,
> we'll have succeeded in generating an unmaintainable mess (tm). It will not be
> any fun to look up things in PMS anew everytime you edit something.

I suspect that most devs just edit things that they maintain, and that
means that they can control how many EAPIs are in use in those
ebuilds.  Again, devs already have incentive to make their own lives
earlier - we don't need to turn that into policy.

I might see some benefit for devs who routinely modify stuff that they
don't maintain, but that should generally be kept to a minimum anyway.
 If unsure how how to edit any particular ebuild, just file a bug!
And if the package isn't maintained, then nobody will be bumping its
EAPI anyway.

Rich

Re: [gentoo-dev] EAPI usage

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 2135 bytes --]

> > <rant>
[...]
> > standards. So, we declare that gcc-4.5 has to be enough for everyone,
> > we'll just keep it in tree forever and dont bother anymore with all
> > these superfluous "does not build with gcc-4.7" bugs.
> 
> That is not an appropriate analogy, as I'm not suggesting that we
> refuse to support newer EAPIs.  I'm just saying that packages
> shouldn't be bumped just for the sake of bumping them.

Well I'm also not "suggesting" that we refuse to support newer gcc. Just, if a 
package does not build with newer, meh, why care. Take old one.
</rant>

> I might see some benefit for devs who routinely modify stuff that they
> don't maintain, but that should generally be kept to a minimum anyway.
>  If unsure how how to edit any particular ebuild, just file a bug!
> And if the package isn't maintained, then nobody will be bumping its
> EAPI anyway.

True but... we do have some fluctuation, and developers come and go. Who can 
update the ebuild better, someone who has maintained it for a while and is 
familiar with its details and the current eapis, or someone who has just 
picked up its pieces.

What I dont actually understand at all is why bumping the EAPI should be so 
complicated or involved that it even deserves so much resistance... 

OK there may be miraculous eclasses (or one in particular) which change api 
radically from eapi to eapi, but I think we've already decided long time ago 
that this is a bad thing(tm) and should not be done. So let's hope it will not 
happen again. 

Other than that, I can not remember any ebuild where the EAPI bump alone took 
me more than 5min. Now take the frequency of new eapi's coming out, and 
compare it with the time that you need for a version bump of a package anyway 
(check upstream changelog, verify dependencies have not changed, do a test 
build, check for correct installation locations, ...)

As an additional bonus this keeps your memory fresh about all the great new 
features...

Cheers, 
Andreas

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] EAPI usage

[Rich Freeman]

On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> What I dont actually understand at all is why bumping the EAPI should be so
> complicated or involved that it even deserves so much resistance...

<rant>Ok, it REALLY annoys me when people pull out this kind of a line
in an argument...  If it isn't all that complicated or involved and it
just makes so much sense, then why do we bother to waste time asking
for it to be made policy, since obviously everybody will just do it
anyway...

Believe it or not, people who take up an opposing side in a debate
don't ALWAYS do it because they're simply dumber than you.  That is,
unless they're arguing with me...  :)  </rant>

>
> As an additional bonus this keeps your memory fresh about all the great new
> features...

Yes, but keeping around all those old EAPIs keeps your memory fresh
about how those ones work.  As an additional bonus, you don't have to
bother to figure out how the new ones work unless you actually need a
feature offered by them.  :)

Rich

Re: [gentoo-dev] EAPI usage

[Michael Orlitzky]

On 09/02/2012 09:46 AM, Rich Freeman wrote:
> On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
>> What I dont actually understand at all is why bumping the EAPI should be so
>> complicated or involved that it even deserves so much resistance...
> 
> <rant>Ok, it REALLY annoys me when people pull out this kind of a line
> in an argument...  If it isn't all that complicated or involved and it
> just makes so much sense, then why do we bother to waste time asking
> for it to be made policy, since obviously everybody will just do it
> anyway...
> 
> Believe it or not, people who take up an opposing side in a debate
> don't ALWAYS do it because they're simply dumber than you.  That is,
> unless they're arguing with me...  :)  </rant>
> 


I think everyone would be happier if all ebuilds in the tree were EAPI4.
On the other hand, Rich is right that making this a policy will have the
opposite of the intended effect: developers just won't fix bugs in
EAPI<4 ebuilds when they don't have time to do the EAPI bump (one could
easily spend a few hours on this).

As a compromise, it could be made policy that "bump to EAPI=foo" bugs
are valid. If someone would benefit from such a bump, he can file a bug
and know that it won't be closed WONTFIX. On the other hand, the dev is
under no more pressure than usual to do the bump.

[gentoo-dev] Re: EAPI usage

[Duncan]

Michael Orlitzky posted on Sun, 02 Sep 2012 10:36:13 -0400 as excerpted:

> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
> are valid. If someone would benefit from such a bump, he can file a bug
> and know that it won't be closed WONTFIX. On the other hand, the dev is
> under no more pressure than usual to do the bump.

This looks like a reasonable compromise indeed. =:^)

Tho I'd still suggest that like other "low priority" bugs, the package 
maintainer can still resolve it as LATER, BLUESKY (tho AFAIK gentoo's 
bugzilla doesn't have that one), or even WONTFIX (as opposed to 
INVALID).  The bug should be considered valid, so INVALID isn't correct, 
but disallowing WONTFIX simply gets in the way of proper communication.  
If a package maintainer WONTFIX, it's better to let them actually SAY 
that, so the bug filer can get on with life, knowing they'll have to 
longterm maintain their own overlay copy if they want the EAPI bump bad 
enough, than to have the bug simply sit there, ignored.

Talking about which. what about a resolution PATCHESACCEPTED?  IOW, I 
don't care enough to bother with it myself, but if you provide the patch, 
I'll take it.  Tho I guess WORKSFORME sort of fits, if the definition is 
bent far enough.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] EAPI usage

[Brian Harring]

On Sun, Sep 02, 2012 at 10:36:13AM -0400, Michael Orlitzky wrote:
> On 09/02/2012 09:46 AM, Rich Freeman wrote:
> > On Sun, Sep 2, 2012 at 9:10 AM, Andreas K. Huettel <dilfridge@gentoo.org> wrote:
> >> What I dont actually understand at all is why bumping the EAPI should be so
> >> complicated or involved that it even deserves so much resistance...
> > 
> > <rant>Ok, it REALLY annoys me when people pull out this kind of a line
> > in an argument...  If it isn't all that complicated or involved and it
> > just makes so much sense, then why do we bother to waste time asking
> > for it to be made policy, since obviously everybody will just do it
> > anyway...
> > 
> > Believe it or not, people who take up an opposing side in a debate
> > don't ALWAYS do it because they're simply dumber than you.  That is,
> > unless they're arguing with me...  :)  </rant>
> > 
> 
> 
> I think everyone would be happier if all ebuilds in the tree were EAPI4.
> On the other hand, Rich is right that making this a policy will have the
> opposite of the intended effect: developers just won't fix bugs in
> EAPI<4 ebuilds when they don't have time to do the EAPI bump (one could
> easily spend a few hours on this).
> 
> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
> are valid. If someone would benefit from such a bump, he can file a bug
> and know that it won't be closed WONTFIX. On the other hand, the dev is
> under no more pressure than usual to do the bump.

If you attach a patch and have done the legwork, sure.

If you're just opening bugs w/ "bump to EAPI=monkeys", bluntly, it's 
noise and it's annoying.  EAPI bump requests for pkgs that need to 
move forward so an eclass can be cleaned up/moved forward, sure, but 
arbitrary "please go bump xyz" without a specific reason (and/or 
legwork done if not) isn't helpful.  Kind of equivalent to zero-day 
bump requests in my view in terms of usefulness.

~harring

Re: [gentoo-dev] EAPI usage

[Michael Orlitzky]

On 09/04/2012 05:06 PM, Brian Harring wrote:
>>
>> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
>> are valid. If someone would benefit from such a bump, he can file a bug
>> and know that it won't be closed WONTFIX. On the other hand, the dev is
>> under no more pressure than usual to do the bump.
> 
> If you attach a patch and have done the legwork, sure.
> 
> If you're just opening bugs w/ "bump to EAPI=monkeys", bluntly, it's 
> noise and it's annoying.  EAPI bump requests for pkgs that need to 
> move forward so an eclass can be cleaned up/moved forward, sure, but 
> arbitrary "please go bump xyz" without a specific reason (and/or 
> legwork done if not) isn't helpful.  Kind of equivalent to zero-day 
> bump requests in my view in terms of usefulness.

Except this is what we have now, and isn't a compromise at all.

Re: [gentoo-dev] EAPI usage

[Mike Gilbert]

On Tue, Sep 4, 2012 at 9:03 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> On 09/04/2012 05:06 PM, Brian Harring wrote:
>>>
>>> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
>>> are valid. If someone would benefit from such a bump, he can file a bug
>>> and know that it won't be closed WONTFIX. On the other hand, the dev is
>>> under no more pressure than usual to do the bump.
>>
>> If you attach a patch and have done the legwork, sure.
>>
>> If you're just opening bugs w/ "bump to EAPI=monkeys", bluntly, it's
>> noise and it's annoying.  EAPI bump requests for pkgs that need to
>> move forward so an eclass can be cleaned up/moved forward, sure, but
>> arbitrary "please go bump xyz" without a specific reason (and/or
>> legwork done if not) isn't helpful.  Kind of equivalent to zero-day
>> bump requests in my view in terms of usefulness.
>
> Except this is what we have now, and isn't a compromise at all.
>

What use is a bug report requesting an EAPI bump for no reason? There
is no sense in "compromising" and creating such a policy if nobody
actually benefits from it.

Re: [gentoo-dev] EAPI usage

[Michael Orlitzky]

On 09/05/2012 12:15 PM, Mike Gilbert wrote:
> On Tue, Sep 4, 2012 at 9:03 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
>> On 09/04/2012 05:06 PM, Brian Harring wrote:
>>>>
>>>> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
>>>> are valid. If someone would benefit from such a bump, he can file a bug
>>>> and know that it won't be closed WONTFIX. On the other hand, the dev is
>>>> under no more pressure than usual to do the bump.
>>>
>>> If you attach a patch and have done the legwork, sure.
>>>
>>> If you're just opening bugs w/ "bump to EAPI=monkeys", bluntly, it's
>>> noise and it's annoying.  EAPI bump requests for pkgs that need to
>>> move forward so an eclass can be cleaned up/moved forward, sure, but
>>> arbitrary "please go bump xyz" without a specific reason (and/or
>>> legwork done if not) isn't helpful.  Kind of equivalent to zero-day
>>> bump requests in my view in terms of usefulness.
>>
>> Except this is what we have now, and isn't a compromise at all.
>>
> 
> What use is a bug report requesting an EAPI bump for no reason? There
> is no sense in "compromising" and creating such a policy if nobody
> actually benefits from it.
> 

If there's really no reason, why would anyone bother to file a bug for
it? It's better for developers than the must-bump policy, and better for
users than what we have now.

Re: [gentoo-dev] EAPI usage

[Rich Freeman]

On Thu, Sep 6, 2012 at 1:03 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> If there's really no reason, why would anyone bother to file a bug for
> it? It's better for developers than the must-bump policy, and better for
> users than what we have now.

What change is even being proposed?  If there is an issue that
actually impacts users, then that issue is the bug, and bumping the
EAPI is just the solution to the bug.

If an ebuild unnecessarily ignores CFLAGS, or if it is a blocker to
some eclass update, or whatever, then that is already considered a
valid bug.

That is my main concern with all of this stuff - just state what you
need in terms of outcomes, not solutions.  If you can't identify the
outcome, then there is no need for the change anyway.  By all means
suggest solutions in the report, but don't confuse the solution with
the problem.

Rich

Re: [gentoo-dev] EAPI usage

[Brian Harring]

On Tue, Sep 04, 2012 at 09:03:55PM -0400, Michael Orlitzky wrote:
> On 09/04/2012 05:06 PM, Brian Harring wrote:
> >>
> >> As a compromise, it could be made policy that "bump to EAPI=foo" bugs
> >> are valid. If someone would benefit from such a bump, he can file a bug
> >> and know that it won't be closed WONTFIX. On the other hand, the dev is
> >> under no more pressure than usual to do the bump.
> > 
> > If you attach a patch and have done the legwork, sure.
> > 
> > If you're just opening bugs w/ "bump to EAPI=monkeys", bluntly, it's 
> > noise and it's annoying.  EAPI bump requests for pkgs that need to 
> > move forward so an eclass can be cleaned up/moved forward, sure, but 
> > arbitrary "please go bump xyz" without a specific reason (and/or 
> > legwork done if not) isn't helpful.  Kind of equivalent to zero-day 
> > bump requests in my view in terms of usefulness.
> 
> Except this is what we have now,

Yes, I stated it because I view it as useful/sane.

> and isn't a compromise at all.

I think you're mistaken in assuming a compromise is the required 
outcome of this.  Given the choice between something productive, and 
something not productive, you don't choose the quasi-productive 
solution.

Bluntly, chasing EAPI versions w/out gain is a waste of time; others 
may think "but it should be EAPI4- the latest!"- and they'd be wrong.  
You bump when there is a reason to do so, or when from a maintenance 
standoint you've got time (now) to do so and can push it forward- 
getting ahead of future work.  Keep in mind the rule "every change 
carries a risk"- while the risk is generally stupidly low, it's 
something I don't think you're being cognizant of in this notion of 
trying to get everything at EAPI whatever.

Filing a bunch of "please bump this to EAPI-whatever" is just annoying 
nagging, it doesn't accomplish anything nor is the ticket particularly 
useful on it's own.  A "Please bump to EAPI4 due to issue xyz" is 
useful- there is a core reason beyond "hey, EAPI4 is the latest AND 
EVERYTHING MUST BE THE LATEST GREATEST!!!" :)

Same angle for EAPI5 and user patching... yes, devs will have a reason 
to move it forward, but user patching is going to be used by a *small* 
fraction of our userbase.  Meaning if you want it, you're likely going 
to need to do the legwork bumping things forward, else you're on the 
devs time/prioritizations.

Not saying it's perfect, but the comments above are realistic rather 
than trying to compromise against the realities of the situation. ;)
~harring

Re: [gentoo-dev] EAPI usage

[Michael Orlitzky]

On 09/05/2012 05:29 PM, Brian Harring wrote:
> 
> Yes, I stated it because I view it as useful/sane.
> 
>> and isn't a compromise at all.
> 
> I think you're mistaken in assuming a compromise is the required 
> outcome of this.  Given the choice between something productive, and 
> something not productive, you don't choose the quasi-productive 
> solution.

From a developer's perspective, it's obviously better to be able to do
whatever you want. But for users it'd be nice to be able to request a
bump to EAPI5 and not get told to buzz off.

Some people are unhappy with the current situation or this thread
wouldn't exist. A good compromise should make everyone just a little bit
unhappy =)

Re: [gentoo-dev] EAPI usage

[Rich Freeman]

On Thu, Sep 6, 2012 at 1:16 PM, Michael Orlitzky <michael@orlitzky.com> wrote:
> From a developer's perspective, it's obviously better to be able to do
> whatever you want. But for users it'd be nice to be able to request a
> bump to EAPI5 and not get told to buzz off.

It is easy.  Don't ask for a bump to EAPI5.  Ask for support for user
patches, or whatever it is that you really need.

I don't exactly see threads all over the place complaining about
legitimate bugs being closed as WONTFIX.

Rich

Re: [gentoo-dev] EAPI usage

[Brian Harring]

[-- Attachment #1: Type: text/plain, Size: 1322 bytes --]

On Sep 6, 2012 10:18 AM, "Michael Orlitzky" <michael@orlitzky.com> wrote:
>
> On 09/05/2012 05:29 PM, Brian Harring wrote:
> >
> > Yes, I stated it because I view it as useful/sane.
> >
> >> and isn't a compromise at all.
> >
> > I think you're mistaken in assuming a compromise is the required
> > outcome of this.  Given the choice between something productive, and
> > something not productive, you don't choose the quasi-productive
> > solution.
>
> From a developer's perspective, it's obviously better to be able to do
> whatever you want. But for users it'd be nice to be able to request a
> bump to EAPI5 and not get told to buzz off.
>
> Some people are unhappy with the current situation or this thread
> wouldn't exist. A good compromise should make everyone just a little bit
> unhappy =)

Open source is built on scratching your own itch.  As I said, you want
eapi5 for user patching, either you're on the devs prioritization, or you
do it yourself.  You may not like that fact, but that *is* reality- filing
nagging tickets isn't really going to help (more likely to piss people off
in the same way zero-day tickets do).

Suggest you put effort towards eapi5 rather than this thread; the thread
isn't productive any longer (arguing the point when people have said no in
full force is pointless).

~harring
>

[-- Attachment #2: Type: text/html, Size: 1696 bytes --]

Re: [gentoo-dev] EAPI usage

[hasufell]

On 08/30/2012 12:28 PM, Johannes Huber wrote:
> Hello gentoo devs,
> 
> From last council meeting summary:
> [snip]
>> Open floor
>> ==========
>> scarabeus suggested the change "dev should use latest eapi when bumping"
>> to "dev must use latest eapi when bumping if not forbidden by eclasses".
>> He was asked to bring it up on the mailing lists, to get a better
>> definition of when what EAPI should be used.
> [/snip]
> 
> I raised the issue through scarabeus, as in my opinion there is no reason to 
> not use latest EAPI. So please discuss.
> 
> Greetings,


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.

Re: [gentoo-dev] EAPI usage

[Johannes Huber]

> 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

Re: [gentoo-dev] EAPI usage

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1165 bytes --]

Am Donnerstag, 30. August 2012, 12:59:07 schrieb hasufell:
> 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.

a) Easier eclass maintenance. 
Restricting the kde4 eclasses to EAPI 3 and 4 made the code indeed simpler. 
We'll raise that to 4 only soon (after fixing the remaining ebuilds in the 
tree.)

b) Easier overall tree maintenance.
I've recently removed a useflag on poppler (xpdf-headers for those 
interested). Of course, this involved fixing all in-tree reverse dependencies 
first. Now I consider myself very lucky there, because all except two packages 
were EAPI 4 and I could use (+). One package was EAPI 3 and I unceremoniously 
bumped it to 4. One was EAPI 0. Having fun with || there. 

I dont consider this list complete, feel free to add.

-- 
Andreas K. Huettel
Gentoo Linux developer 
kde (team lead), sci, tex, arm, printing
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] EAPI usage

[Thomas Sachau]

[-- Attachment #1: Type: text/plain, Size: 1773 bytes --]

Andreas K. Huettel schrieb:
> Am Donnerstag, 30. August 2012, 12:59:07 schrieb hasufell:
>> 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.
> 
> a) Easier eclass maintenance. 
> Restricting the kde4 eclasses to EAPI 3 and 4 made the code indeed simpler. 
> We'll raise that to 4 only soon (after fixing the remaining ebuilds in the 
> tree.)

An eclass, which includes helper commands like eutils or versionator
eclass wont benefit from it. Only specific eclasses (like your kde
example would benefit and for those, the related team can always decide
to bump all their packages to the wanted EAPI and then to bump the
eclass requirement. So no need to force this on everyone else.

> 
> b) Easier overall tree maintenance.
> I've recently removed a useflag on poppler (xpdf-headers for those 
> interested). Of course, this involved fixing all in-tree reverse dependencies 
> first. Now I consider myself very lucky there, because all except two packages 
> were EAPI 4 and I could use (+). One package was EAPI 3 and I unceremoniously 
> bumped it to 4. One was EAPI 0. Having fun with || there. 

If a package has a maintainer, you could just ask him to fix the issue,
so you dont have to even think about the EAPI. And if there is no
maintainer, you can take and bump it. And if noone wants to maintain it,
it will be dropped at some point. So you can bump whatever you maintain,
just still the question: Why force this on everyone else?


-- 

Thomas Sachau
Gentoo Linux Developer


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 380 bytes --]

Re: [gentoo-dev] EAPI usage

[Rich Freeman]

On Thu, Aug 30, 2012 at 3:44 PM, Thomas Sachau <tommy@gentoo.org> wrote:
> Andreas K. Huettel schrieb:
>> Am Donnerstag, 30. August 2012, 12:59:07 schrieb hasufell:
>>> 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.
>>
>> a) Easier eclass maintenance.
>> Restricting the kde4 eclasses to EAPI 3 and 4 made the code indeed simpler.
>> We'll raise that to 4 only soon (after fixing the remaining ebuilds in the
>> tree.)
>
> An eclass, which includes helper commands like eutils or versionator
> eclass wont benefit from it. Only specific eclasses (like your kde
> example would benefit and for those, the related team can always decide
> to bump all their packages to the wanted EAPI and then to bump the
> eclass requirement. So no need to force this on everyone else.

Agreed.  I'm fine with asking maintainers to change EAPI in specific
cases where there is a specific benefit.  Diego sends me bug reports
from time to time for whatever odd set of circumstances cause some
kind of problem on a tinderbox, and when I can I fix the bugs and
report upstream.  The result is a better experience for all, even
beyond Gentoo.  If somebody wants to drop code in qt.eclass or
whatever and my bumping EAPI makes their life easier they can always
ask nicely and I'm happy to help out.  What I don't see the value in
is policies that extend the work beyond where the benefit lies.

Rich

Re: [gentoo-dev] EAPI usage

[hasufell]

It's very simple. People will just ignore this if they disagree and
leave any "bump to EAPI-latest already" bugs unresolved forever.

Re: [gentoo-dev] EAPI usage

[Vaeth]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2079 bytes --]

Rich Freeman <rich0@gentoo.org> wrote:

> If I thought that bumping the EAPI would make my life as a maintainer
> easier I'd just do it - I wouldn't need a policy to tell me to do it.

It is not only so much a question of whether it helps you as a
maintainer but more whether it helps the user. And this is the case
for all EAPIs which currently exist.

I am surprised that nobody mentioned the following example:

One of the arguments to introduce the user-patching code into EAPI=5
was that it should work for all packages - not randomly on some but
not on others.  So if in the course of time not all packages are
bumped to at least EAPI=5, this goal cannot be reached by introducing
the feature into the EAPI.

> If I did think that bumping the EAPI wasn't worth the hassle, and yet
> I was told that I'd be banned as a dev for not doing so anyway, then
> obviously I'm going to do the minimum necessary to comply with policy,
> which means changing the EAPI line of the ebuild and only changing
> other lines as required to get the thing to build and comply with PMS.

This is sufficient for 99% of the ebuilds.

> So, while all those benefits you named are "enabled" few would
> actually be realized.

For current EAPIs, most benefits are realized just by bumping EAPI.
For instance, the improved error checking (i.e. dying on certain problems)
happens automatically and might reveal problems which were hidden before.

Also, for EAPI=5, other packages (possibly from overlays) can make use
of slot dependencies from your packages.

OK, for changing from setup tests for USE dependencies and USE_REQUIRE
may require some extra coding (though not much), but again it is
the _user_ who will gain from it a lot.

So in any case, for the _user_ an EAPI bump is (with the current EAPIs)
always a benefit. This should be worth to establish the policy currently.

If this happens to be different in some hypothetical future EAPIs,
this policy can be modified later, correspondingly: It is easy to
change this policy later on, but hard to bump the whole tree later on.

Martin Väth

Re: [gentoo-dev] EAPI usage

[Rich Freeman]

On Sun, Sep 2, 2012 at 6:52 AM, Vaeth <vaeth@mathematik.uni-wuerzburg.de> wrote:
> So in any case, for the _user_ an EAPI bump is (with the current EAPIs)
> always a benefit. This should be worth to establish the policy currently.

Your example only cited cases where an EAPI bump to 5 has a benefit.
If that is the case, I'm fine with making an effort to migrate as many
ebuilds as possible to EAPI 5.

However, what is the benefit to users from migrating to EAPI 1, or 2,
etc?  The policy you're recommending would have required expending
effort to implement every one of those for every ebuild in the tree
without those kinds of end-user benefits.

What will the benefit be for migrating to EAPI 6, or 7, or fred (EAPIs
are not numbers, and they aren't ordered either)?  And since EAPIs
aren't actually ordered, is the latest one whichever is actually last
approved, or the one which is "most functional?"  Suppose EAPI xml
defines an ebuild format in xml that isn't parsed by bash, whose
purpose is mainly to allow simple ebuilds to be simplified further but
which is really only appropriate for 20% of the ebuilds in the tree?
It isn't good to assume that newer EAPIs include all the features of
the earlier ones - they just are different specifications for
behavior.  Maybe somebody will come up with a reason to have an EAPI
that only works with packages that use cmake for building, or
whatever.  The bottom line is that it may be desirable in the future
to have different branches of EAPIs followed by different packages.

So, if we want to make a policy that we should use EAPI5 whenever
possible I'm fine with that, if the benefits to users are worth the
costs.  However, why extend this to every EAPI that follows when the
benefits of those are not yet known?

Let's look at a different situation - --as-needed.  It was realized
that supporting this across the tree has significant benefits for
users, so we made a push to make it happen.  Packages that didn't
support this had bugs filed, and they were fixed, and today it is the
default.  However, what we DIDN'T do is just make a policy that all
packages have to support all possible options in LDFLAGS, but rather
we just focused on the one we actually cared about.

You don't even need a "policy" to enact these kinds of changes.  There
was never a policy that all ebuilds must support --as-needed, and
there may be legitimate reasons for individual packages to not support
it today.  However, when the case was made that this benefits
end-users then everybody just jumped on board, since, well, most of us
are nice guys who do that sort of thing.  :)

Rich

Re: [gentoo-dev] EAPI usage

[hasufell]

On 09/02/2012 12:52 PM, Vaeth wrote:
> Rich Freeman <rich0@gentoo.org> wrote:
> 
>> If I thought that bumping the EAPI would make my life as a maintainer
>> easier I'd just do it - I wouldn't need a policy to tell me to do it.
> 
> It is not only so much a question of whether it helps you as a
> maintainer but more whether it helps the user. And this is the case
> for all EAPIs which currently exist.
> 
> I am surprised that nobody mentioned the following example:
> 
> One of the arguments to introduce the user-patching code into EAPI=5
> was that it should work for all packages - not randomly on some but
> not on others.  So if in the course of time not all packages are
> bumped to at least EAPI=5, this goal cannot be reached by introducing
> the feature into the EAPI.

global epatch_user has a downside which I think was not even really
discussed here unless I missed something. It could introduce many bogus
bug reports which are caused by user-applied patches, cause it's easier
now and you don't need to do it in an overlay.
The maintainer will need to catch this and asking which repo the
bugreporter did use is not sufficient. He will need the build log and
check if user patches got applied there.

Always talking about the benefit for the user and not the time
developers have to spend on things does not catch the whole situation.

>> If I did think that bumping the EAPI wasn't worth the hassle, and yet
>> I was told that I'd be banned as a dev for not doing so anyway, then
>> obviously I'm going to do the minimum necessary to comply with policy,
>> which means changing the EAPI line of the ebuild and only changing
>> other lines as required to get the thing to build and comply with PMS.
> 
> This is sufficient for 99% of the ebuilds.

PMS is a fraction of what is to consider when writing an ebuild. It does
not include QA policies, gentoo policies and whatnot.

> 
>> So, while all those benefits you named are "enabled" few would
>> actually be realized.
> 
> For current EAPIs, most benefits are realized just by bumping EAPI.
> For instance, the improved error checking (i.e. dying on certain problems)
> happens automatically and might reveal problems which were hidden before.

dying on certain problems can be achieved without EAPI bump.

> 
> Also, for EAPI=5, other packages (possibly from overlays) can make use
> of slot dependencies from your packages.
> 
> OK, for changing from setup tests for USE dependencies and USE_REQUIRE
> may require some extra coding (though not much), but again it is
> the _user_ who will gain from it a lot.
> 

If a user wants/needs features of newer EAPIs, because he does some
things in his overlay, he could probably open a bug report with a
proposed patch to the ebuild which bumps the EAPI.

Unless that's the case I would leave it to the developer if he needs
those features or what EAPI he prefers. If a newer EAPI would fix a bug
it might still be solvable without EAPI-bump. Again: leave it to the
developer.

This will create a useless annoyance and I can assure you that
developers WILL ignore this policy/rule. What are you gonna do then?
Just bump it on your own without asking? Take it up to devrel?
It's not really worth it.

The benefits have been stated and it's already advised that developers
keep up with the latest EAPI, but you _cannot_ assume it anyway like
some PMS contributors do.

Re: [gentoo-dev] EAPI usage

[Rich Freeman]

On Sun, Sep 2, 2012 at 8:03 AM, hasufell <hasufell@gentoo.org> wrote:
> PMS is a fraction of what is to consider when writing an ebuild. It does
> not include QA policies, gentoo policies and whatnot.

True, although at least somebody bothers to write PMS down...

Much of the rest is word of mouth, posts on mailing lists, maybe
council meeting minutes, and whatever somebody decides to put in a bug
report or ping you with on IRC.  There are the GLSAs, and then stuff
like guides and the devmanual, which are a blend of must-do, best
practices (which presumably are discretionary), and just illustrative
examples.

Bottom line is that what a developer MUST do is a matter of what
people will bother to complain to Devrel about, and what Devrel will
bother to enforce.  For the most part this boils down to common sense.
 That's why most "developers must do foo" proposals don't end up going
anywhere.  In six months somebody new will join the project and not
even know what they "must" do simply by virtue of the fact that we
won't bother to write it down anyway.

Rich

Re: [gentoo-dev] EAPI usage

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 1278 bytes --]


> Bottom line is that what a developer MUST do is a matter of what
> people will bother to complain to Devrel about, and what Devrel will
> bother to enforce.  For the most part this boils down to common sense.

Err... if that's the part you worry about, I'm personally completely happy if 
we just all agree that it's common sense to stick to the newest council-
approved development with fullest feature set. no need to put it in writing 
any more than as a "strong recommendation". :)

> And since EAPIs
> aren't actually ordered, is the latest one whichever is actually last
> approved, or the one which is "most functional?"  Suppose EAPI xml

To be honest I personally consider that ("eapis are not ordered") an 
abomination, and my personal wish would be to keep them large-scale ordered 
with (among one major version) unordered sub-versions ("4-xxx") if needed. or 
at least keep all PMS-approved eapis ordered. "Experimental eapis for use in 
third party software" should not require any mentioning in pms anyway. :]

However, that is a different discussion. Someday I'll start a separate 
flamewar^H^H^H^H^H^H^Hmailing list thread about it. 

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] EAPI usage

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 839 bytes --]

On Sun, 2 Sep 2012 15:23:58 +0200
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:
> To be honest I personally consider that ("eapis are not ordered") an 
> abomination, and my personal wish would be to keep them large-scale
> ordered with (among one major version) unordered sub-versions
> ("4-xxx") if needed. or at least keep all PMS-approved eapis ordered.
> "Experimental eapis for use in third party software" should not
> require any mentioning in pms anyway. :]

I think you're missing the point of that declaration... It's fine for
you to think of EAPI 4 as being newer than EAPI 3. It's not fine for
you to consider EAPI 4 to be a superset of EAPI 3, and it's not fine to
try using comparisons other than string equality (with the annoying
special case for "" being "0") on an EAPI value.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] EAPI usage

[Alexis Ballier]

On Sun, 02 Sep 2012 14:03:07 +0200
hasufell <hasufell@gentoo.org> wrote:

> On 09/02/2012 12:52 PM, Vaeth wrote:
> > Rich Freeman <rich0@gentoo.org> wrote:
> > 
> >> If I thought that bumping the EAPI would make my life as a
> >> maintainer easier I'd just do it - I wouldn't need a policy to
> >> tell me to do it.
> > 
> > It is not only so much a question of whether it helps you as a
> > maintainer but more whether it helps the user. And this is the case
> > for all EAPIs which currently exist.
> > 
> > I am surprised that nobody mentioned the following example:
> > 
> > One of the arguments to introduce the user-patching code into EAPI=5
> > was that it should work for all packages - not randomly on some but
> > not on others.  So if in the course of time not all packages are
> > bumped to at least EAPI=5, this goal cannot be reached by
> > introducing the feature into the EAPI.
> 
> global epatch_user has a downside which I think was not even really
> discussed here unless I missed something. It could introduce many
> bogus bug reports which are caused by user-applied patches, cause
> it's easier now and you don't need to do it in an overlay.
> The maintainer will need to catch this and asking which repo the
> bugreporter did use is not sufficient. He will need the build log and
> check if user patches got applied there.

it is probably easy to add a big warning 'user patches have been
applied' when emerge bails out because a build failed

Re: [gentoo-dev] EAPI usage

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]

On Sun, 2 Sep 2012 14:54:12 -0300
Alexis Ballier <aballier@gentoo.org> wrote:

> On Sun, 02 Sep 2012 14:03:07 +0200
> hasufell <hasufell@gentoo.org> wrote:
> 
> > On 09/02/2012 12:52 PM, Vaeth wrote:
> > > Rich Freeman <rich0@gentoo.org> wrote:
> > > 
> > >> If I thought that bumping the EAPI would make my life as a
> > >> maintainer easier I'd just do it - I wouldn't need a policy to
> > >> tell me to do it.
> > > 
> > > It is not only so much a question of whether it helps you as a
> > > maintainer but more whether it helps the user. And this is the
> > > case for all EAPIs which currently exist.
> > > 
> > > I am surprised that nobody mentioned the following example:
> > > 
> > > One of the arguments to introduce the user-patching code into
> > > EAPI=5 was that it should work for all packages - not randomly on
> > > some but not on others.  So if in the course of time not all
> > > packages are bumped to at least EAPI=5, this goal cannot be
> > > reached by introducing the feature into the EAPI.
> > 
> > global epatch_user has a downside which I think was not even really
> > discussed here unless I missed something. It could introduce many
> > bogus bug reports which are caused by user-applied patches, cause
> > it's easier now and you don't need to do it in an overlay.
> > The maintainer will need to catch this and asking which repo the
> > bugreporter did use is not sufficient. He will need the build log
> > and check if user patches got applied there.
> 
> it is probably easy to add a big warning 'user patches have been
> applied' when emerge bails out because a build failed

Yes, and it is definitely easier to nice them than the fact that user
has patched the ebuild silently.

That said, I do not really remember users ever doing bogus bug reports.
But well, every reason to complain is good, isn't it?

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 316 bytes --]

Re: [gentoo-dev] EAPI usage

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 745 bytes --]

On Sun, 02 Sep 2012 14:03:07 +0200
hasufell <hasufell@gentoo.org> wrote:
> global epatch_user has a downside which I think was not even really
> discussed here unless I missed something. It could introduce many
> bogus bug reports which are caused by user-applied patches, cause
> it's easier now and you don't need to do it in an overlay.
> The maintainer will need to catch this and asking which repo the
> bugreporter did use is not sufficient. He will need the build log and
> check if user patches got applied there.

No, it's not a downside. It's an advantage: user patches will get
applied correctly now, and in a way visible to the package mangler, and
thus can be shown consistently in bug reports.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]