Thank you, Arthur, for voicing your frustration. We do not have a bullet proof concept how to avoid frustration, but what happened to you seems avoidable.
>>>>> On Fri, 7 Feb 2003 08:27:07 -0900 (AKST), Arthur Corliss ><[EMAIL PROTECTED]> said: > Greetings: > Let me start by saying I know you guys have day jobs as well, but I have to > wonder if I'm following the right procedure on getting modules registered on > CPAN. My last couple of attempts appear to be failing miserably. > First off, my understanding about namespace registration was to submit the > standard form and wait for feedback. I did that with Parse::PlainConfig. As > per 04pause.html: > The module list maintainers themselves are mostly lurkers. You need not wait > for a response. Generally a lack of response can be taken as acceptance of > the module name being proposed. Well, at least there it really says: You need *not* wait. You get maintainer status by simply using a namespace the first time. > I want to point out that Parse::PlainConfig as a name was actually proposed by > one of list maintainers. I accepted the recommendation, and based on the > 04pause.html doc, thought that module was accepted for inclusion. I'm reading the old thread again and I think the problem started with the namespace Parse::PerlConfig. Tim said: Perhaps Parse::PlainConfig. Seems more natural to me that 'RCfile', especially given the existance of Parse::PerlConfig. Parse::PerlConfig is not registered and imho is a bad precedent. Parse:: modules should deal with parse algorithms: Lex, RecDescent, Tokens, YALALR, Yapp are dealing with the task of parsing in a generic sense. I agree with brian that modules for reading config files should live in the Config or ConfigReader namespace. > A month ago, I find out from brian d foy that my module was > *never* registered officially on CPAN, and yet I've already > polluted that namespace. And since he's opposed to the name, I > know I have no chance of getting it registered under that name. Oh well, I think, I'm ready to break down. Not by the namespace choice but by the fact that Tim's statement looked pretty approving and quite a lot of time has passed since. It's not acceptable for the users of your module to now reject a namespace proposal such a long time after it seemed to be approved. If nobody objects within the next three days, I'll approve Parse::PlainConfig. > Fast forward to the last few weeks. I have a new module that I'd like to > register (Class::Aggregate). I'll warrant that I didn't fully research out my > options before proposing it (and I thank all of you that pointed me in the > right direction), but since then I've found that none of the existing modules > a) fit my feature criterion, and b) can easily be combined with other modules > to do so without considerable overhead, either. > After some discussion, at least one of you seemed open to having it uploaded > to CPAN, but wanted a name change. I can't think of anything better, so I > took a recommendation from you guys, once again. > What I'm finding is that even if I accept your recommendations, that namespace > is *still* not officially registered on CPAN, nor can I update module > metadata via the pause interface. If you mean Class::EHierarchy, I've registered that now. > I'm loathe to upload anything you guys don't approve of out of respect for the > archive. I don't want to hijack any namespace that the community doesn't feel > is appropriate. > So, what am I doing wrong? Can I get modules registered, or am I just > supposed to go away? I apologise if any of you feel that I'm being a pain in > the ass. Either tell me to go away (which I will comply with), or give me a > procedure that will work. CPAN is extremely tolerant in what it accepts. It works without human intervention. First-come-first-served is the default. It's the extra blessing of being registered in the module list that needs human intervention and this is a painful bottleneck. We do not know how this can be improved. You could perhaps adjust your expectation: ask us for advice and feel free *not* to accept it. The number of CPAN developers who either ignore us completely or do not follow our suggestions or did not get any good suggestions from us seem to be the majority, and yet CPAN works mostly. -- andreas
