"Chris Weyl" <cweyl(a)alumni.drew.edu> writes:
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? :)
Chris,
Thanks for the ideas - responding inline.
* 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).
I don't know if it makes sense to include all the core modules as BR's -
I think we first need to decide exactly how far this split is going, and
then it will be more clear which BR need to be explicitly stated.
* 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.
For now, at least, list list is low-traffic enough to support the
SWAT-type activities...we just need to define how we interact with the
package owners, and get their buy-in/permission/forgiveness.
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.
Yeah, this has been one of my back-burner ideas for awhile now, too. I
don't think there's anything really magical or hard here we just need to
get it on someone's front burner and get it done. I'll see about taking
a stab at it in the next couple of weeks and see how far I get.
* 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.
It looks pretty good to me - how would you like feedback? Shall I edit
the wiki, or send you diffs?
* 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.
I'll try to do better with this for F8 - unfortunately perl stuff got
pushed too far out in the cycle of things I pay attention to during F7's
dev cycle.
A couple of things specifically I'd like to look at early in F8 in
addition to your list:
o Finalize 'the split' - which packages do we still want to split from
perl? All of them?? If we do split everything out that we can, we
probably need some sort of 'perl-core/perl-devel/perl-everything'
meta-goodness.
o Fix up the dependencies, (probably) remove the 'devel' rpms from the
buildroots, the and anaconda set of default RPMS.
- And fix the dependencies on other perl-* packages.
o Remove the %perlmodcompat stuff, unless someone has a good reason to
keep it.
-RN
--
Robin Norwood
Red Hat, Inc.
"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching