Thoughts...
Robin Norwood
rnorwood at redhat.com
Fri May 18 18:33:41 UTC 2007
"Chris Weyl" <cweyl at 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
More information about the Fedora-perl-devel-list
mailing list