Thoughts...

[Chris Weyl]

On 5/18/07, Robin Norwood <rnorwood at redhat.com> wrote:
> "Chris Weyl" <cweyl at alumni.drew.edu> writes:
> > * buildrequres for perl modules.
[...snip...]
> 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.

I'm inclined to steer away from BR'ing non-split core modules myself.
The problem then becomes one of defining the list of split core
modules and insisting on those -- but I don't think we'll have that
final list locked down for, oh, a month or so I suspect.  (Given F7
out and a little time for things to calm down.)

I see two advantages to BR'ing all modules, core or not:
* There's never a question of if something needs to be BR'ed
* If we split more off in the future, we don't have to worry about
adding them to all the specs

> > * co-maintainership.
[...snip...]
> 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.

Yeah.  Ideally the distinction would be SIG members vs random
maintainer who just happens to have a perl package (e.g. people who
care about perl in Fedora as a whole vs people who just care about
their packages).  Ideally we'd be able to help manage major changes
(like the split) as well as cover for each other when life / Real Job
/ etc takes precedence.  (Happens to all of us from time to time.)

This is something that appropriate infrastructure can facilitate and enable.

> > * infrastructure.
[...snip...]
> 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.

I suspect there are several of us who have already written some
variant of a "check version against CPAN" script out there; it might
just be possible to modify one (or more) of those to run periodically
and stick the output into a wiki page / email / custom page / etc
somewhere.

As an aside, I'm certainly willing to help out with writing /
implementing these tools.  Actually, if I have some free time this
weekend maybe I'll take a first pass at adapting my check-cpan script
to dump out a static page and post it somewhere for people to
critique.

I also have a (horribly messy) script to handle the gruntwork of
putting a package up for review:  ftp'ing it somewhere, creating the
review bug; posting long reviews and toggling flags.  It uses the
bugzilla xml-rpc commands (that I know of, at least) to perform these
functions.  I'll see if I can't clean it up some and get it out
there...  If anyone knows more about the xml-rpc interface to
bugzilla, I'd be very interested in hearing about it :)

> > * perl packaging guidelines could use some love.
[...snip...]
> It looks pretty good to me - how would you like feedback?  Shall I edit
> the wiki, or send you diffs?

Excellent :)  Whatever you feel is most appropriate -- it is a wiki,
so I don't see any reason why we all can't just edit it directly.

> > * SIG communication and coordination.
[...snip...]
> 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.

No worries.  Again, I'm not criticizing anyone in particular, but
rather trying to offer some feedback as we go forward.

> 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.

Sounds good by me :)

                                        -Chris
-- 
Chris Weyl
Ex astris, scientia