Hey, I just found this: According to paragraph 5b in the module list
docs, uploading "locks" the namespace on a first-come-first-served
basis, which might be why the docs say several times to register
namespaces before uploading, to keep people from stepping on each
other unknowingly. Is this still true, and am I reading it right?
On Mon, Apr 16, 2001 at 09:18:22AM +0200, Andreas J. Koenig wrote:
> >>>>> On Sat, 14 Apr 2001 17:34:37 +0200, [EMAIL PROTECTED] (Johan Vromans) said:
> jv> What do we think would be the typical sequence of steps?
>
> jv> 1. A user wants to share a Perl module.
>
> jv> 2. Before sending the module to CPAN things like naming and API must
> jv> be discussed. I think comp.lang.perl.modules should be used for
> jv> this.
>
> jv> 3. The user applies for a CPAN id.
>
> jv> 4. To allow the people at c.l.p.m. access to the new module, it needs
> jv> to be stored somewhere. CPAN would be great, but then we have a
> jv> catch-22 situation.
How about ftp://pause.kbx.de/incoming?
> jv> I think that it is quite pointless to ask on the user registration
> jv> form what the user wants to contribute. Often, this is interpreted as
> jv> a request for module registration.
>
> The tieing of user- and modules registration IMHO has the side effect
> that people perceive user registration as something that needs to be
> carefully considered. It has kept CPAN so much smaller than
> sourceforge and perceived as higher quality. It's highly desirable
> that we do not lose this.
I think a good goal might be to go ahead and automate both user and
module registrations.
You might be able to unlink user and module registration and keep the
ID namespace from cluttering up if you expire authors who have never
uploaded modules 90 days after registration.
One way to keep module quality high might be to start using
cpan-testers results to control DSLI to some degree.
Here's a clean flow, I think -- it avoids most name changes, should
increase quality, and makes better use of the 'idea' stage:
1. Developer needs to write a Perl module.
2. Developer discusses name, API, prior art, etc. on c.l.p.m.
3. Developer registers as CPAN author if they aren't already. (web form)
4. Developer applies for temporary modlist namespace reservation,
entering 'SLI' but not 'D'. Formal notice automatically mailed to
[EMAIL PROTECTED] (web form)
5. Modlist maintainers grant namespace reservation for 90
days, renewable. Reservation is shown as 'idea' stage.
6. Developer starts writing code, uploads iterations to PAUSE.
7. Registration switched out of 'idea' to 'construction' stage
after cpan-testers returns positive results on at least 1 platform.
8. Developer advances DSLI settings via existing web form as module
matures.
If I understand things right, the above flow would need the following
code beyond what's there now:
- one web form for user registration
- one web form for module namespace reservation
- something to record the granting date and automatically expire
unused namespace reservations (how is the modlist edited now? web,
CLI, or vi?)
- something to sniff cpan-testers results and update the DSLI
We could eventually put the reservation granting in step 4 up for a
vote by existing registered authors, letting modlist maintainers take
a little more of a break as volume increases.
One problem with the above s that I've slightly redefined what "idea"
stage means -- rather than meaning "up for adoption" it would mean
"no uploads yet".
I can see other variations on this; for instance, rather than
redefining 'idea', we could add a 'name reserved' stage or something.
Steve
--
. . ` *
Steve Traugott ` . * +
Enterprise Systems Architect + `
[EMAIL PROTECTED] ' * . ' +` *
