Ciaran McCreesh wrote: > On Thu, 13 Aug 2009 12:50:26 +0000 (UTC) > Mark Bateman <coul...@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 ;-)
