Re: Thoughts...

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



"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


[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Legacy Announce]     [Fedora PHP Devel]     [Kernel Devel]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Big List of Linux Books]     [Gimp]     [Yosemite Information]
  Powered by Linux