Thoughts...

[Robin Norwood]

Ralf Corsepius <rc040203 at freenet.de> writes:

> On Fri, 2007-05-18 at 14:33 -0400, Robin Norwood wrote:
>> "Chris Weyl" <cweyl at alumni.drew.edu> writes:
>> I don't know if it makes sense to include all the core modules as BR's -
>
> It does, because this is the only way to guarantee long term stability.
> IMO, the confusion you see know largely is only a side-effect of the
> perl-module packaging having been "too lax" so far. If all perl-modules
> packaging would have applied stricter rules, you'd be able to move
> perl-core modules between packages, and nobody would have noticed.
>
> "BR-ing core-modules in *.specs", in practice condenses to a handful of
> modules, namely those explicitly required by a module's build
> infrastructure. Anything else will be pulled in automatically.

I think we need to decide exactly what the goal is with splitting out
the core modules - some people think we should split them all out,
others want a smaller set.  I'm not really sure which is best at the
moment...I think it requires more discussion.

>> 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.
> ... We would have had opportunities to gain clarity, if you had not
> reverted the split.

This isn't actually true.  The modules are still split out.  The changes
were to make the perl-devel require the other split modules, and include
the split modules in the default install.  You can still remove
perl-devel + co at install time or later, if you wish.

And yes, this is two steps forward, one step back.  I wasn't really very
happy with it, but enough people were going to be negatively impacted by
this change that spot and I both decided it would be best to go this
way.  I would rather have made a clean split instead of doing it this
way, but I have to accept that we didn't give enough warning to make
people comfortable with this change.

> Now, I can only urge you to revert your recent changes for rawhide (F8)
> ASAP.

I agree.  I'll look at it Monday, unless one of the co-maintainers gets
to it first.  :-)

>> > * 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.
> Well, meanwhile, given how the merger changes Fedora's workflow, I am
> not sure anymore if a "SWAT" team can work. Things which had been easy
> before (and to some extend could have been scripted), now seem to become
> inapplicable ...

I'm not really sure what you mean here...what specific problems do you
see?

[...]

>> 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.
> Steven Pritchard has/had a couple of nice scripts.

Yeah, I believe I've seen them on the wiki.

>> > * 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 :)
> Is there a need to do so? I don't think so.
>
> Build.PL or Makefile.PL should not matter at all (It matters that a
> package builds) - Some CPAN authors prefer Build.PL, I hate it and
> consider it to be "mal-designed junk".
>
> We have other "semi-written rules" which are much more of importance
> (e.g. perl modules must own all dirs not owned by the "perl" or
> "filesystem" packages).

I think documented best practices are a good idea - if there's debate
between possible options, we can present both of them along with pros
and cons.

>> > * 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 
> Glad to hear you say this - I am pretty disappointed about seeing the
> split effectively having been reverted, last minute. 

Again, they weren't reverted - though I take your point that including
them default is practically the same thing.

> Changes, I had invested quite some considerable time in, because I had
> thought you were aiming at getting them into FC7 - Apparently, I was
> wrong.

I had planned to, but was convinced that the disruption to users and
developers would be too great.  I probably should've brought you into
the discussion, considering the contributions you'd made.  Sorry!

>> - 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.
> The split should be focused on separating "*devel" from "runtime".
>
> That was the motivation to split out "MakeMaker", CPAN, and Test::
> modules (*devel packages).

That's my gut feeling about it - but some people seem to think it would
be worthwhile to split out everything.  That approach would make it
easier to update 'core' module piecemeal if needed to fix bugs - but
leads to a lot of packages to have a 'core' perl distribution in
Fedora.  So, I think more discussion is warrented.

>> 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.
>
> * Clean up rpm not to provide bogus libXXX.so's on perl's dynamically
> loaded *.so. Probably all of them are "plain wrong".

Ok.  I think we have a pretty good hit list going here.  I'll put them
up on the wiki somewhere this weekend.

Thanks,

-RN

-- 
Robin Norwood
Red Hat, Inc.

"The Sage does nothing, yet nothing remains undone."
-Lao Tzu, Te Tao Ching