[gentoo-dev] Re: Re: RFC: Make 10.0 profiles EAPI-2 'compliant'

[Steven J Long <slong@rathaus.eclipse.co.uk>]

Ciaran McCreesh wrote:

> On Thu, 13 Aug 2009 12:50:26 +0000 (UTC)
> Mark Bateman <couldbe@soon.com> wrote:
>> > On Wed, 12 Aug 2009 20:41:30 +0200
>> > Tomáš Chvátal <scarabeus <at> gentoo.org> wrote:
>> > > Also we should allow the stuff as directory thingus (portage
>> > > already handles it right).
>> > 
>> > That's a seperate thing that needs EAPI control. You'll need to
>> > propose it for EAPI 4 if you want that.
>> 
>> Except this "stuff as directory" was pre-EAPI and thus the PMS should
>> have captured that as EAPI-1
>> Ergo PMS is wrong and needs to be updated to refect reality
> 
> PMS accurately reflects the Portage documentation and the commit
> message that introduced the feature -- it's purely for use
> in /etc/portage/, which is beyond the scope of PMS.
>
If it's pre-EAPI it's part of EAPI '0'. That you neglected to document it,
for whatever reason, is irrelevant.
 
> It is not the business of PMS to enforce undocumented features
It's not undocumented, as you just pointed out above.

> that Portage supports only by accident
Oh, so now you know the minds of the portage developers?

I'd like to present an alternative viewpoint: portage developers are happy
to work to PMS, since it has utility for users. But ultimately, they're not
that bothered about pushing for new things, since the process means dealing
with you; adding features for portage only and leaving it up to the wider
community to push for them in EAPIs is an awful lot less hassle.

> and that aren't used in the tree. 
>
Circular argument, don't you think? It's not in-tree so we won't put it in
PMS. It's not in PMS, so it's not allowed in-tree.

And don't forget, we have to "claim PMS compliance" to which you are the
gatekeeper.
 
I'd like to ask the Council to consider whether EAPI development has not in
fact supplanted a large part of the GLEP process (specifically the
technical aspects to do with ebuild development.) As such, insisting on all
discussion on bugzilla is in fact a subversion of the original process that
people have agreed upon.

-- 
#friendly-coders -- We're friendly but we're not /that/ friendly ;-)