FAQ
Here are the minutes from the CPAN BOF at YAPC::America::North,
Sat. June 16 2001 at the Delta Hotel.

In attendance were roughly 40 people in attendance, gathered to discuss
some outstanding issues with CPAN, and ways to fix them.

The agenda as discussed was as follows:
Group Authorship
Build (+ build requirements)
Test.pm and it's alternatives
perlmodstyle (+h2xs)
CPANTS
[Damian's interlude]
CPAN Bug Reporting
Group CVS
Versioning
Module ratings
Perl6 Library
PPM
NAPC [Ingy's idea of rethinking CPAN and the Perl Core modules]
interfaces
code review
scripts
modules@perl.org

Z.

-------------------------

Group Authorship
Group IDs are available
SPUG is a group ID
Reefknot was prevented
shouln't have to lie with pause
ingy didn't run into the problem
bad precedence?

spug is a group defined by people, reefknot is defined by a project

reefknot wasn't presented as vaporware

inline is now group authored; other should follow this example
last uberrelease was done in 8 trials from a website; CPAN is a code
repository; alpha things out doesn't scale on CPAN; versioning is
another issue; core group works on development, informally, but
publishes URLs publically

reefknot is developed on sourceforge, release on CPAN; 3 possible IDs
but no one knew which ID would publish reefknot

one person with one ID insures consistency

pumpking should be identified by the CPAN ID

still up in the air

Resolution: open issue

Build (+ build requirements)
Remake MakeMaker without make; current code is fossilized, and no one
understands it anymore (except Sarathy)

MakeMaker must go;

Basic flaw: uses make; overpowered for most modules on CPAN; instead
of running Makefile.PL; determine 90% of the functionality people use
and put it into a config file; MakeMakerNG reads the manifest,
configuration and does all of the basic stuff; process for the module
author is a lot simpler as a result (Include simple XS code)

anything more complicated (TK) would still need to call make/cons/etc.

focus on how module writer writes the code, not how to download
binaries thorugh PPM

should simplify the way modules are installed should be simplified for
80% of all users installing modules

Brian: MakeMaker isn't evil, if you never look at it; use stable
processes in place, make a dead simple interface for building modules

oneliners should package a tarball and go

Wrap something over MakeMaker and rewrite the underlying implementation
can go later.

If we redo makemaker, a whole host of security issues disappear;
Makefile.PL is no longer untrusted; configuration file is more secure

Action Item: create a series of interfaces, and see which ones works

Action Item: Talk to Andreas

Test.pm and it's alternatives
Test.pm used to be the only thing to write tests (and Test::Unit)

Test.pm isn't very well documented at all

Schwern started working on alternative modules: Test::More - everything
you ever wanted to do with testing

Edge cases from perl-qa list: no one writes tests at all. Solution:
Test::Simple, with a single method

Test::Harness is being refactored (Ingy: needs to work with -T)

Test::Simple/Test::More are out there, but no one knows about them yet

Action Item: Test Tutorial manpage (perltesttut)

Test::Harness has been fossilized for a very long time; a few new
features added but nothing big;

Open issue: remote installation and checking whether remote tests are
OK; requires print interface to go away (or not be the only interface)

Create simple tests for each bug report

Resolution: discuss further on perl-qa@perl.org

perlmodstyle (+h2xs)

Before we start rewriting modules for Perl6, start codifying good
module style; we're better at writing modules now than when Perl5 was
released

Skud working on perlmodstyle in POD and possibly a PDD for Perl6

Summary:
Before you start writing a module
designing and writing a module
documenting your module
release considerations

Tests should be pulled out of release considerations

Version control should be pulled out

release considerations should be renamed

Issue: difficult to identify which releases support which features

Not everyone is running all back releases to test compatibility

Action Item: automation script for testing modules against back
releases


Before you start writing a module:
has it been done before
if it's been done in perl, don't reinvent the wheel (?)
if a module does almost what you want, start with a patch,
take over maintainership, etc.
do one thing, do it well
modules should be modular
- clearly defined scope, one sentence
What's in a name
- descriptive
- consistent with existing module names


Emphasis on suggestions, not "thou shalt not"

This is only a style guide, not a tutorial on everything you want to do

Issue: package naming (esp. without make dist)
docs are hard to find

Perl Debugged is the first book that goes through MakeMaker very well

perldoc (5.6.1) perlnewmod: tutorial on writing a modules; focuses on
how; perlmodstyle focuses on what to do after you've started writing a
module


Designing and writing a module:
whether or not to use OO
defining your API
naming conventions
parameter passing
design for flexibility
specify your version requirements

Document your module well
Document for the user

release considerations
Version numbering
Prereq modules, dependencies
Packaging (standard packaging)
Testing
backwards compatibility (maintain it)
Licensing
Error handling


Action Item: help writing whether or not to use OO:
rrwoo@cpan.org, schwern@pobox.com

Action Item: more contributions on 'defining your API'

Action Item: add common pitfalls

Action item: whether we can use this as an evaluation tool with CPAN
modules; [bleed into cpants?]

h2xs: if there is a good style for writing perl modules; start with
newpm (starts with suggested style)

Action item: Don't focus exclusively on starting, focus equally on
creating a module with existing code as well (Ingy)

Idea: Autogenerate POD stubs, POD Test stubs, similar to javadoc
(New Perl Module Wizard)

Testing, Module Authoring Tools, Distribution

CPANTS
Test for good style (based on perlmodstyle)

Modules vs. Packages: packages are the foundation of automation and
testing

2500 named packages (current version), 1900 in october, 1400 authors;
most haven't submitted anything, of those who submit, most submit only
one module; a few dozen submit multiple modules

making the barriers to entry high is one way to ensure good code on
CPAN, but it's a crappy way to go about it

Natural selection through ratings?

Should stop saying "put it on CPAN?" No.

What's a good module? We can write it down, but can't automate it;
human intervention required; use Kwalitee (like Quality, but much
easier to measure). Look for the dirty ashtrays, test what's easy to
test

Look for qualities that good modules tend to have:
README
MANIFEST
Makefile.PL
Tests, pass tests
*.pm files compile
works with all perls in current use
works with all common perl configurations

test coverage
complexity rating (B::Fathom)
ratio of code::docs

Not required to "pass" all tests; need to figure out what lets 80% of
modules through the barrier

Key principle: don't trust the module author

PPM/Automated Build process: test tests that author wrote; 1 failure
out of 3 or 1 failure out of 6000?

CPANTS stores metadata about module testing; sometimes OK when modules
fail with good cause

CPANTS always maintains a human face

CPANTS heuristics should be constantly adjusted; bootstrap with known
sets of modules that are reeelly good and reeelly bad; CPANTS should
agree with these heuristics

CPANTS isn't just a rating system; it could be a tool for module
authors

Issue: Module abandonment: nag list (similar to a centralized bug
repository); also a way to determine how well a module is maintained

Issue: Kudos list; more reviews; ratings

CPANTS's principle is to build and agglomerate existing technologies
and produce new modular technologies

CPANTS also exists to test new versions of Perl

Action Item: distributing the workload

Action Item: B::Simple - require a backend for processing Perl code

Action Item: Break up CPAN.pm and PPM.pm

Absence of CPANTS approval doesn't mean a module is bad; presence of
CPANTS approval doesn't mean that a module is good, it has a good
chance of being good

Sourceforge: cpants-devel, cpants-announce

Damian interlude:
at the end of the bell curve

Simplifying module creation is a good thing

Too overwhelmed, probably won't manage a nag list, bug reporting db,
etc. and will probably get a bad rating with CPANTS

People will ignore the red bells around CPANTS ratings stating that
this module is well written, but not necessarily good

Automated distribution tools do sound like a good idea (won't
necessarily use them myself)

Like the idea of a replacement for h2xs (probably won't use them)

CPANTS is essential; need as much feedback as I can get; cpan-testers
is incredibly useful to me; can't test on the mac anymore; testing
needs to be expanded

ought to have a way to test whether a module runs on every platform,
with a list of modules it doesn't work on

some proposed features would be better if they were opt-in/opt-out
(Kudos list, nag lists, bug databases, etc.)

People do this work out of the goodness of their own heart on their own
time or stealing time from their boss; produce tools that help people
to spend their time better, but don't rag on them for not being as
active as possible

CPANTS might be better as opt-in

Schwern: 20% of CPAN is used regularly; get constant feedback; written
by the few authors writing more than one+ modules; those authors are
already getting good feedback; need to get good feedback to authors
with one/two modules on CPAN.

CPAN Bug Reporting
set up gnats/bugzilla/etc. for all of CPAN, one per module/author

perl -MInline reportbug; tar it up and email to author; ought to be
more core to the language

Produce automated reporting tools; more reason to make it standard

Action item: ReportBug module by Damian and Ingy

Mail volume is an issue

Issue: mark modules as abandoned by author

Action Item: reportbug should feed the bug reporting database

Opt-in by virtue of author's inclusion of ReportBug support

DocBugs identified by dozens of different errors with different
explanations on different platforms with the same module version;
can be identified by standard preamble

Action Item: determine a premable to quickly identify common errors

Group CVS
Action item: Ask Ask to open up CVS on onion for public r/w

Action Item: Ask Ask to set up group perms and assignment of group
perms for CVS projects

Issue: Possibly reuse sourceforge code

Issue: Aegis

Action Item: Implement Aegis on top of CVS/Perforce; talk to schwern

Versioning:
Big sky issue

Larry is aware of the problem; big problem

discussed over perl6 lists; huge issue with large multinational data
centers

Apache::Auth is a bear; 3 authors, 3 releases

API Change triggers major version increase: social issue; s/b in Skud's
document

Back versions of RecDescent need older versions of Perl, and are still
supported

CPAN Filters; alternative repositories, overlaid; repository for code
work with 5.004, 5.005, 5.6.1, etc.; point at an old repository for an
old version

Module ratings
deferred to cpan-workers@perl.org

Perl6 Library
deferred to perl6-stdlib@perl.org

Topics: should Perl6 should have a standard library? What should be in
it? Requirements?

PPM:
PPM is currently a bad implementation of a great idea; AS has done a
lot work improving it recently

Look for better things to come out of PPM from ActiveState soon

PPM is a copy of the blib directory and performs a 'make install',
and does cleanup (#! paths, adding HTML docs in the doc tree)

No one has built alternative repositories of modules

Configuration in Makefile.PL? It handles ~98% of what's out there

NAPC:
Napster & CPAN

If you build something on one machine, you can give it to someone on
another machine (with a similar architecture/perl/etc.)

Once someone has built a module once, all of the QA has been done

totally opt-in

The idea is thus:
opt-in for all time, and subversively always turn on napc sharing

Sociological problems
Bell curves
target versions of perl most widely in use (business installs)
if you can help all of all the major perls being used, it is
ultimately better than fixing something moving forward
window is moving forward; help as many people as we can

Putting modules in the core only help people going forward; causes a
predjudice; reduce module dependencies in your modules, because many
users shun modules that have large amounts of dependencies; once a
module goes into the core, it's there frozen for ever (even bad
interfaces)

I don't want to rip apart MakeMaker, CPAN.pm, PPM; work around them

An idea like NAPC won't require any changes to what you're doing now;
an ease-of-use premise can be easier; nothing in the core, but
everything you need will be there

everything should be on an equal footing

issues: where an external library is installed, #! line in a script

A tarball has a unique MD5;
two MD5s; one for the system; when system MD5s are equal, the systems
are equivalent

anything I need on your system automatically installs on my system when
I need it

a master list matches up md5s of systems with md5s of tarballs; how do
we populate this list? a couple of possible trust systems you can use;
certain trusted members who haven't broken trust propogate a trusted
key; if 100 untrusted members come up with the same key, it's a trusted
key

(potential for damage where anyone can create a trusted module; cpan
has no security at the moment; if someone wants to attack the perl
community, there is no defence through cpan)

("security through not having a house": use core modules only, choose
not to download anything through CPAN)

can create a core with a trusted list (off of CD perhaps)

damian on the core: one of the issues we have is that the people who
comes to these conferences are at the high end of the bell curve; the
expectations of this set of what is easy to do doesn't mesh with the
idea of what's easy to do for the average user. CGI is in use because
the amount of work to install it is zero.

should everything in the core today be in tomorrow's core? out of the
box for perl6, you get all of the things you expect to get (great
success of Java; you get 325,000 classes that come with it; no CPAN
necessary)

the unfortunate thing about the perl5 core, it's not relevant for what
most people are doing; people don't want CGI, they want something more
sophisticated (Text::Template, Mason, etc.) it's no good that any
group sits down and determines what should be in the perl6 core because
it isn't a representive group;

need another RFC process to determine not what should be in there, but
what you have and what you use today; people want a simple life; perl
should just work

----

the number of users who can work without a core is not a minority; 10
companies on wall st., each with more restrictive environments than
most of us are used to; perl should have everything there

seething masses of perl programmers want XML::Parser, Database stuff,
and GUIs easily;

napc won't stop any process currently in use, just gives you more
options

napc is about lowering the barrier of entry for cpan modules; cpan
shell isn't required to install by hand; get rid of the stigma of using
cpan modules

buildfarms will probably fail; but if everyone is part of the
buildfarm, that would be a great success

a module in the core is in the core because it's usually very good;
core also defines standard set of modules, and tend to get used whether
or not they're the best modules to use; to know what's available, you
have to visit CPAN (and know that CPAN exists, and how to install from
CPAN)

Damian: I want to create a new modules; wanted to use filter::simple,
and not worry about putting it into a dependency file; I have to decide
what filter::simple is, and it comes along for free; that's important

(module author knows modules are on CPAN, but end-user doesn't need to
know about filter::simple)

Redesigning the core re-cannonizes what's worthwhile to be in the core;
remember that people work in snapshots; they're going to need to be
backwards compatible

Brian: if the core were to go away, it would be in about 10 years;

interfaces:
tabled

code review:
tabled

scripts:
should be really obvious to package a script as a module/distribtion

Action Item: improve module authoring tools to create scripts

modules@perl.org:
[general dissatisfaction]

upload process for new module authors kinda sucks

slow response

this is why cpan as we know it is disorganized

modules@perl.org is a lot of unfun human effort; is there any way to
get this stuff happening? Registering namespaces [automated request],
etc.

appearing in the modules list is a different issue entirely

lots of problems: what needs to be solved? shouldn't put more people
on the job (either the job sucks, or it needs more people, or...)

issues: administering cpan vs. other tasks (registering namespaces)

response has to be fast

should be tabled until TPC when people who have the power to do
something will be available

most of the problem is simply about not having enough resources; this
is not just malicious malingering; it's a thankless job, too

existing namespaces are ill-defined; need a reorganization and cleanup
of the module namespaces; done with stupid modules (ACME::*) - people
will accept the modules moving around; not that disruptive to
reorganize it

Action Item: tutorial on how to change the name the name of your module
without breaking compatibility

Action item: look at the namespaces that are there, and figure out what
they're good for (Skud)

Adding some automation should help; codify what people are doing now so
people who join can draw upon an expert knowledgebase

Action item: produce a decision tree to determine the name of a module
based on some naming guidelines (used when naming a module using h2xs)

Issue: incredible floating namespace problem

die "this module is deprecated"

module-authors@perl.org: dormant mailing list where this can be
discussed

YAS is looking at sponsoring more than just people like Damian; also
important to sponsor people who are doing the real work (maintainers,
pumpkings, patchers, etc.); perl's greatest strength and greatest
weakness is that we're all volunteers; this is not an immediate
solution, but something that is being considered very seriously.

Action item: Identify the requirements for a solution to solve
outstanding issues with CPAN

Master todo list / apprenticeship database
it would be good to have an apprenticeship database instead of a talk
at YAPC

apprenticeship would work well with the first layer of aegis

we need something better than an ad-hoc PHP collaboration tool (e.g.
sourceforge)


Mailing lists:
modules@perl.org
moudle-authors@perl.org
cpan-workers@perl.org
perl-qa@perl.org
perl6-stdlib@perl.org
perl-sdk@perl.org
cpants projects on sourceforge

Search Discussions

  • Elaine -HFB- Ashton at Jun 20, 2001 at 3:14 am
    http://sourceforge.net/projects/cpants/

    I'd like to see CPANTS materialise in some form before anything else comes
    down the pike as most of this other stuff is out of the scope of CPAN. From
    the looks of that URL, it might be a while unless it's being held somewhere
    else.

    Also, insulting the modules@ people is rude without asking for
    clarification first. Suggesting that there is prejudice without
    justification is highly inflammatory. It's not a terrific way to engage in
    productive dialogue either.

    And since this list got the 'ratings' "action item", I'll grab the moment
    to say the same thing we all said last year. Ratings is a sucky idea, but
    people are free at any time to go ahead at any time, stop talking about
    it, and implement their own system to prove it one way or another.

    e.
  • Ask Bjoern Hansen at Jun 20, 2001 at 2:58 pm

    On Tue, 19 Jun 2001, Adam Turoff wrote:

    Group Authorship [...]
    reefknot is developed on sourceforge, release on CPAN; 3 possible IDs
    but no one knew which ID would publish reefknot
    So?

    In any case, Andreas (and/or Jarkko) explained it well (summary:
    it works as designed) elsewhere to Skud (I think it was).
    CPANTS [...]
    making the barriers to entry high is one way to ensure good code on
    CPAN, but it's a crappy way to go about it
    Jon Orwant thinks the barriers to entry being too high. We talked
    about this at the CPAN meeting at TPC4. I don't remember the
    consensus.
    Group CVS
    Action item: Ask Ask to open up CVS on onion for public r/w

    Action Item: Ask Ask to set up group perms and assignment of group
    perms for CVS projects
    I'd rather have us just use SourceForge if the code is going to be
    public anyway.
    Versioning:
    Big sky issue
    We talked about this extensively at the CPAN meeting at the last
    TPC. Sarathy, Larry, Tim Bunce, Jarkko, Graham and many others were
    there and had all kinds of good ideas.
    PPM: [...]
    No one has built alternative repositories of modules
    I don't use Windows, but last I checked there was a few alternative
    PPM repositories. (Or maybe I'm misunderstanding something).
    modules@perl.org:
    [general dissatisfaction]

    upload process for new module authors kinda sucks
    What sucks about it?
    slow response
    Read the FAQ. http://www.cpan.org/modules/04pause.html#namespace
    "You need not wait for a response. Generally a lack of response can
    be taken as acceptance of the module name being proposed."
    this is why cpan as we know it is disorganized

    modules@perl.org is a lot of unfun human effort; is there any way to
    get this stuff happening? Registering namespaces [automated request],
    etc.
    Eh, it does work automagically.

    [snip]




    - ask

    --
    ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
  • Adam Turoff at Jun 20, 2001 at 10:57 pm
    For those of you not at YAPC, this BOF started out as Schwern wanting
    to hack CPANTS. During YAPC, Skud had an idea for perlmodstyle, and
    the BOF was scheduled on Saturday to talk about CPANTS, Skud's doc[o],
    and general CPANy bits.

    40 people showed up, some who have been using Perl for 3 months. This
    was not intended to be a working group, but a general discussion about
    CPAN. What you've read in the minutes is little more than people expressing
    their personal opinions.

    Aside from a bunch of people stating their opinions, this module was
    moderatly useful: a few people shared some good ideas, and a bunch of
    CPAN users stated where they're comfortable and uncomfortable with CPAN;
    if we want to clean up CPAN, here are some issues to address (either with
    upgrades to PAUSE/CPAN, or more/better/more visible docs).

    Among the true fruits of this meeting are:
    skud got some feedback on perlmodstyle
    Ingy and Damian agreed to work on ReportBug.pm
    Schwern talked about CPANTS again
    Damian shot down the idea of converting CPAN into Sourceforge,
    overloading Ask and onion, and creating more vehicles
    to whine, whimper and moan to module authors

    You can consider everything else to be user feedback which may or may
    not be meaningful.
    On Wed, Jun 20, 2001 at 07:58:31AM -0700, Ask Bjoern Hansen wrote:
    On Tue, 19 Jun 2001, Adam Turoff wrote:
    Group Authorship [...]
    reefknot is developed on sourceforge, release on CPAN; 3 possible IDs
    but no one knew which ID would publish reefknot
    So?

    In any case, Andreas (and/or Jarkko) explained it well (summary:
    it works as designed) elsewhere to Skud (I think it was).
    I think shane raised the issue, and skud talked to the issue somewhat.
    shane sounded like she was finding issues with the design (I think).

    It sounds like the policy needs to be clarified, possibly more publically.
    No more no less. This is just a whine, and some other projects may be
    whining about policy for the same reason. It doesn't sound like there's
    a real problem to solve here.
    CPANTS [...]
    making the barriers to entry high is one way to ensure good code on
    CPAN, but it's a crappy way to go about it
    Jon Orwant thinks the barriers to entry being too high. We talked
    about this at the CPAN meeting at TPC4. I don't remember the
    consensus.
    We spoke on both sides of the issue. Both sides have merit. This group
    didn't come to a conclusion.
    Group CVS
    Action item: Ask Ask to open up CVS on onion for public r/w

    Action Item: Ask Ask to set up group perms and assignment of group
    perms for CVS projects
    I'd rather have us just use SourceForge if the code is going to be
    public anyway.
    The action item was to 'Ask Ask', not 'Overload Ask'. :-) 'No' and
    'use Sourceforge' are perfectly acceptable answers.
    Versioning:
    Big sky issue
    We talked about this extensively at the CPAN meeting at the last
    TPC. Sarathy, Larry, Tim Bunce, Jarkko, Graham and many others were
    there and had all kinds of good ideas.
    Someone raised the issue (I forget who). When it was time to discuss
    it, we shot it down for further discussion because it was a thorny
    issue that greater minds were thinking about.
    PPM: [...]
    No one has built alternative repositories of modules
    I don't use Windows, but last I checked there was a few alternative
    PPM repositories. (Or maybe I'm misunderstanding something).
    CPAN isn't mirrored in full as PPM distributions. ActiveState used
    to maintain 150+/- out of a possible 1600 distributions. Now, it's
    about 1200/2100. That, and it's not clear where the alternative
    PPM repositories are.

    Choose who you want to blame on this one. More whining and moaning,
    nothing more.
    modules@perl.org:
    [general dissatisfaction]

    upload process for new module authors kinda sucks
    What sucks about it?
    Read that as [whine moan whimper grunt].
    slow response
    Read the FAQ. http://www.cpan.org/modules/04pause.html#namespace
    "You need not wait for a response. Generally a lack of response can
    be taken as acceptance of the module name being proposed."
    Read that as people not reading the FAQ. MPEG at 2300. :-)

    Z.
  • Ask Bjoern Hansen at Jun 20, 2001 at 11:09 pm

    On Wed, 20 Jun 2001, Adam Turoff wrote:

    40 people showed up, some who have been using Perl for 3 months.
    This was not intended to be a working group, but a general
    discussion about CPAN. What you've read in the minutes is
    little more than people expressing their personal opinions.
    Ok, thanks for clarifying.

    To us who were not there it seemed like a group of people decided to
    "fix CPAN" without quite knowing what they were fixing. :-)

    [...]
    Among the true fruits of this meeting are:
    skud got some feedback on perlmodstyle
    Ingy and Damian agreed to work on ReportBug.pm
    Schwern talked about CPANTS again
    Damian shot down the idea of converting CPAN into Sourceforge,
    overloading Ask and onion, and creating more vehicles
    to whine, whimper and moan to module authors

    You can consider everything else to be user feedback which may or may
    not be meaningful.
    Then it all sounds good; thanks.



    - ask

    --
    ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
  • Elaine -HFB- Ashton at Jun 21, 2001 at 12:51 am
    Adam Turoff [ziggy@panix.com] quoth:
    *>
    *>Among the true fruits of this meeting are:
    *> Schwern talked about CPANTS again

    Did he indicate if any work has been done on it? I found a home for the
    box I gave to the PM for it and have it slated for shipping out to
    webster.edu in 2 weeks where it will serve as a second search.cpan box as
    well...so it would be nice to know if there is anything to host at this
    point.

    e.
  • Adam Turoff at Jun 21, 2001 at 2:57 am

    On Wed, Jun 20, 2001 at 07:50:52PM -0500, Elaine -HFB- Ashton wrote:
    Adam Turoff [ziggy@panix.com] quoth:
    *>Among the true fruits of this meeting are:
    *> Schwern talked about CPANTS again

    Did he indicate if any work has been done on it? I found a home for the
    box I gave to the PM for it and have it slated for shipping out to
    webster.edu in 2 weeks where it will serve as a second search.cpan box as
    well...so it would be nice to know if there is anything to host at this
    point.
    Schwern?

    Z.
  • Michael G Schwern at Jun 25, 2001 at 2:28 am

    On Wed, Jun 20, 2001 at 07:50:52PM -0500, Elaine -HFB- Ashton wrote:
    Adam Turoff [ziggy@panix.com] quoth:
    *>
    *>Among the true fruits of this meeting are:
    *> Schwern talked about CPANTS again

    Did he indicate if any work has been done on it? I found a home for the
    box I gave to the PM for it and have it slated for shipping out to
    webster.edu in 2 weeks where it will serve as a second search.cpan box as
    well...so it would be nice to know if there is anything to host at this
    point.
    Work? If by "work" you mean "code", no.

    However, I appear to have found a partner-in-crime in the person of Ingy.


    --

    Michael G. Schwern <schwern@pobox.com> http://www.pobox.com/~schwern/
    Perl6 Quality Assurance <perl-qa@perl.org> Kwalitee Is Job One
    That which stirs me, stirs everything.
    -- Squonk Opera, "Spoon"

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcpan-workers @
categoriesperl
postedJun 20, '01 at 12:44a
activeJun 25, '01 at 2:28a
posts8
users4
websitecpan.org

People

Translate

site design / logo © 2021 Grokbase