Re: A Semi-Public Version Control Repository for Your CPAN Modules

[Frank Wiles]

On Tue, 27 Jun 2006 00:42:58 +0300
Shlomi Fish <[EMAIL PROTECTED]> wrote:

> I really don't want to do that, because it's not a real solution.
> This mailing list, modules@perl.org and other forums are inundated
> with such requests for gaining maintainership of authors who
> disappeared. Now Damian did not disappear - he's still alive and
> kicking - he just doesn't have the time to apply all patches or fix
> all bugs. 
> 
> Once a FOSS project becomes popular and the author becomes busy, then
> having only one person able to commit changes to such a project,
> scales less and less. That's what version control and multiple
> commiters (or alternatively or complementarily distributed version
> control) is for. 

  You can have co-maintainers in CPAN today that allows for multiple
  people to inject "real" versions into CPAN.  But you have to be
  setup by the maintainer as a co-maintainer. 

  But like with all FOSS projects, I think it should be up to the
  current maintainer ( or the CPAN gods if the maintainer disappears )
  to grant that.  Limiting commits to just people with PAUSE logins
  would probably not cause too many problems... but the chance for
  abuse is still higher than I would like if the decision were up to 
  me. 

  As for your ideas on "vendor" tags, in-house CPAN sources, etc. I
  think can all be handled adequately today with CPAN::Mini and 
  injecting your own modules.  Obviously, you'd have to host these
  yourself and point your cpan shell at them, but it should work 
  with todays tools. 

 -
   Frank Wiles <[EMAIL PROTECTED]>
   http://www.wiles.org
 -

Documentation-only Module

[John M. Gamble]

After some consultation, I've decided to take David Golden's suggestion
and create a package that will hold the PDF article on cubics.  I also plan
to use his suggestion on a name: Math::Polynomial::Solve::Doc.

That leaves a question of the layout of the package.  I probably don't need
to lay out an extended directory structure, since there isn't an 
installation

process.  But would you expect a META.yml file?  How about a Build.PL file?

If you would expect a META.yml file, what lines would you expect in it?
Name and version, of course.  Anything else?

As an aside, it looks like the license (brought up by Chris Dolan) will be a
Creative Commons, since the other licensing schemes are more oriented
towards source code.  This is not in the list of valid licenses as known by
Module::Build::Base.  Should I just choose "unknown" for the META.yml file,
if the file is needed?

As a further aside, when I looked for the license list many of the sites 
found by
Google say that one should "[s]ee Module::Build 
 for the list of 
valid options"

(the site  is one such
example).  Module::Build doesn't list the valid licenses.  One has to search
Module::Build::Base, and even then it's not documented - I had to search
the code.

Thank you for your help.

   -john


"Deathbot 9000 would rather avoid Internet drama."
   Questionable Content #642
   http://www.questionablecontent.net/view.php?comic=642