FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor


 
 
LinkBack Thread Tools
 
Old 08-30-2012, 10:28 AM
Johannes Huber
 
Default EAPI usage

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
 
Old 08-30-2012, 10:57 AM
Rich Freeman
 
Default EAPI usage

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
 
Old 08-30-2012, 10:59 AM
hasufell
 
Default EAPI usage

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.
 

Thread Tools




All times are GMT. The time now is 01:39 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org