"Chris Weyl" <cweyl@xxxxxxxxxxxxxxx> 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
