Thoughts...

[Chris Weyl]

Hey all --

What with all the recent turmoil surrounding the Infamous Perl Split
of naught-seven, I thought I'd take a few minutes and put down some of
the areas in which I feel might need a little work.  I don't intend
for this note to spark a fire, or to be taken as anything but healthy,
constructive criticism, but a solid discussion of these issues should
provide for a stronger perl SIG going forward.

What was the old Klingon adage?  That which does not kill us makes us
write more one-liners?  :)

* buildrequres for perl modules.

Until just recently, it was considered poor form to include core perl
modules as buildrequires; now for a few of them we have to.  Do we
want to start including all core modules as BR's, or just the ones
that have been split off?  Regardless, we should document this (say
under PackagingDrafts/Perl).

* co-maintainership.

For the record, if there's something that needs to be done to any of
my perl packages, I don't have a problem with it.  (E.g. a coordinated
effort to add the newly-missing br's to them, etc).  I only ask that
the minimum change necessary be made, a note be sent to this list, and
a reasonable effort be made to contact me first.  I rather like Ralf's
idea of a "SWAT team", but I don't think it needs to be phrased as
such: as a SIG cooperating together to improve the state of Perl in
Fedora as a whole we can accomplish much.

As we package more and more of CPAN, this is definitely an area we
should examine.

This leads nicely into...

* infrastructure.

It just struck me that we have but a fraction of the "good" CPAN
modules in Fedora, and as I push towards packaging more of Catalyst
etc that number is going to rise.  Fortunately, CPAN itself makes
keeping track of these packages (and updates, etc) much easier -- and
I have a couple scripts written to, e.g., compare the version in devel
and the version in CPAN, etc.  If we put a little effort into it,
there's no reason we couldn't create a framework to regularly check
packaged versions vs CPAN versions and post the results somewhere.
--say in a Fedora-hosted project.  (perl.fedoraproject.org anyone?
<grin>)  Such an approach would benefit us all.

A cpanspec-like tool to update specs, check br's, run a build and
rpmlint it to assist with updates would also make life much easier.

* perl packaging guidelines could use some love.

One of the things I've been becoming acutely aware of lately is that
there's a large body of customs and best practices in terms of
packaging perl modules that we've built up over the years.  From
things like "prefer Build.PL over Makefile.PL" to simple things like
"It's 'GPL or Artistic', not the other way around", we have a
consensus on The Reasonable Way To Package Modules.

However, it's not written down anywhere :)

I've been updating PackagingDrafts/Perl periodically over the last few
weeks.  I don't think we need to set down hard and fast rules, but a
document like this, that the perl SIG take ownership of, would help
communicate these best practices to newbies.

* SIG communication and coordination.

If there's one thing that the recent perl split has exposed, it's that
there are some strong opinions about the proper way to do things, held
by many people -- myself included :)  In an environment like this,
it's critical (IMHO) to lead up to major changes through a through and
open discussion on the list (and perhaps IRC).  An attempt at reaching
a consensus should be given serious effort, and changes should be done
in a reasonable way (e.g. in the beginning of a development cycle).
Even if a consensus cannot be reached, a reasonable effort at it will
help everyone accept the outcome.

Very few of us here are paid to do this.  We're here for a variety of
reasons, all of which are valid, and because of that it's even more
important for us to be engaged as a community, and to feel that we
have a stake (and say!) in it.

Whew!  Ok.  Time for more coffee :)

                                     -Chris
-- 
Chris Weyl
Ex astris, scientia