On Thu, Feb 22, 2007 at 04:13:11AM +0000, Ciaran McCreesh wrote: > On Thu, 22 Feb 2007 04:04:37 +0000 Steve Long > <[EMAIL PROTECTED]> wrote: > | In process terms, I can't understand why the team working on it isn't > | a pkgcore dev (eg marienz if you can't communicate with ferringb) > > Because a) they haven't asked,
Since I'm a relatively active pkgcore dev and listed explicitly in the text you reply to, I'm going to assume I'm part of the "they" here. I have not asked for access to PMS. The whole process of "only people we deem sufficiently skilled get access" makes me a bit uncomfortable. For example, what if I managed to get through whatever process there is for verifying if I'm capable of contributing, and then am unable to actually contribute because of time constraints? I'm afraid that would effectively reduce my "credit" for participating in future projects of the same kind. That's sort of a worst case scenario though. And it's likely I do lack the knowledge and experience to contribute a lot to this specification, but that is a bit hard for me to judge without being able to see what is there already in the first place. > b) they're more interested in replacing the ebuild format I am very curious where you got that idea. No, I am not interested in replacing the ebuild format. Nor is any other pkgcore dev as far as I know. I do have a few ideas for extensions to the format, which work together with the EAPI proposal. > c) every other time they've gotten involved they've been highly > unhelpful. Do you have any examples in mind here? I can't think of one, I'm curious what project you are referring to. No longer in reply to this particular mail, but to the thread in general: I am a bit unsure about what the goal for PMS is here. It does not seem to be to document what a certain (the current?) version of portage does, as the defacto standard. Instead you want to document what portages *intention* is, or something like that. That obviously sounds like an excellent idea, but as far as I know most of the PMS contributors are also Paludis devs. Paludis, being an alternative to portage, is *also* trying to handle ebuilds the way portage is "intended" to handle them. So what I'm afraid of is that "by the time that Paludis 1.0_pre is released" we will simultaneously see PMS released to the public, and Paludis 1.0_pre supporting that PMS perfectly, with all deviations on the part of portage (or pkgcore) being considered "bugs" in their implementation of the specification. This does not go into just how far PMS might end up deviating from existing portage behaviour and existing ebuilds in the tree, and how much of that is acceptable for a specification that is intended to be picked up by the council as something official all ebuilds and managers must adhere to. We have already seen some examples where code used in ebuilds currently in the tree would be invalid under the new specification. It does not seem right to me to have a specification like this (which if it gets picked up by the council all tree ebuilds and all package managers should comply with) written mostly by developers of a single package manager (no pkgcore devs have access to the PMS spec at the moment. I do not know who *does* have access though. Is there a list somewhere, or do you need to have access to get at the list? :) ). Most of this could be countered by saying that there should be a "reference package manager" to go along with the specification, but I am not convinced this is the right approach here, since a reason to write this specification to begin with was to be able to figure out which of the package managers are viable portage alternatives. The idea was to not get any messy portage quirks documented as required standard behaviour, the risk here is that we'll now get paludis quirks documented as required standard behaviour. -- Marien.
pgpL3ElYSvXzs.pgp
Description: PGP signature
