On 5/18/07, Robin Norwood <rnorwood@xxxxxxxxxx> wrote:
"Chris Weyl" <cweyl@xxxxxxxxxxxxxxx> 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
