On Sat, 8 Feb 2003, Andreas J. Koenig wrote:
> 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.
:-) Thanks for hearing me out.
> Well, at least there it really says: You need *not* wait. You get
> maintainer status by simply using a namespace the first time.
I understood that, but it seemed that it might be a bit aggregious to go ahead
and use a space that might be contested later, or used for more appropriate
purposes by someone else. For that reason, I've made the personal decision
not to upload anything that isn't signed off on.
> 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.
I understand both brian's and your arguments, and as I said to him, I wish he
had pointed that out back then, I would have changed the module name to
something else.
> 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.
Keep in mind, I haven't decided the best course of action on that module
myself. I've taken what brian said to heart (though I still have a few
objections), and the users that I'm in contact with have already been warned
that there may be a name change in the future. The biggest quandry I have is
a matter of cleaning up: do I risk breaking existing scripts out there by
deleting Parse::PlainConfig from CPAN? Or do I just funnel all future
development into another namespace?
> If you mean Class::EHierarchy, I've registered that now.
:-) Much obliged.
> 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.
I have a tremendous respect for you guys, so I don't think I'd feel
comfortable acting unilaterally. I also understand that what you guys do for
CPAN is on your own time, so I don't expect immediate responses. I just don't
want to move forward for many *months* like I did on Parse::PlainConfig just
to find that you had more input on it. I was concerned that Class::EHierarchy
would end up the same way.
--Arthur Corliss
Bolverk's Lair -- http://arthur.corlissfamily.org/
Digital Mages -- http://www.digitalmages.com/
"Live Free or Die, the Only Way to Live" -- NH State Motto
