Ciaran McCreesh wrote: > On Thu, 13 Aug 2009 19:22:16 +0100 > Steven J Long <sl...@rathaus.eclipse.co.uk> wrote: >> > 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. > > No, it's not part of EAPI 0. If it's a feature that is pre-PMS, it's part of EAPI-0. The definition is flexible, presumably to avoid this kind of runaround.
> It's an accident. If you'd like another > example of an accident, Portage won't complain if you stick garbage in > certain metadata keys; this does not mean PMS should say that it's > legal to put garbage in metadata keys. > That's irrelevant and you know it, apart from being one of your usual political digs at portage. >> > It is not the business of PMS to enforce undocumented features >> It's not undocumented, as you just pointed out above. > > Using it in the tree is undocumented. But it's not an "undocumented feature" is it? > Using it in user configuration is beyond the scope of PMS. Define 'user' >> > that Portage supports only by accident >> Oh, so now you know the minds of the portage developers? > > Yes. No, you clearly do not, as this shows: > I know that they said when adding the directory feature that it > was for use in user configuration files. That's what the commit message > said, and that's what the documentation patch said. The documentation > change explicitly only allowed the feature in user configuration, not > the tree. > > Had the feature intended to be tree-usable, the documentation change > would have said so. > Thanks for explaining what "the Portage documentation and the commit message" means. And yeah, you can read it. Well done. It *does not* mean you know what future directions might have been envisaged. <snip> >> > 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. > > That's only a circular argument if you snip out the rest of the > sentence. > Nonsense. You gave the fact that it's not used in the tree as a reason not to put it in PMS, did you not? I merely addressed it separately, since it is a distinct semantic component. >> 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. > > Moving the discussion to bugzilla was the Council's decision, not mine. > Yes, well, I didn't ask you. I asked the Council to consider the broader picture, which is their role, since effectively GLEPs are now only for non-technical things, or might as well be, since all future ebuild directions are EAPI by definition. Having wider input (which is what this list is for) might avoid future blind-alleys. Nevertheless, I'm sure they'll take your valuable insight under consideration, as well as the history and any lobbying that might have gone on at the time, assuming they were around and haven't suppressed the memory. -- #friendly-coders -- We're friendly but we're not /that/ friendly ;-)
