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? :)
* 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).
* 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.
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.
* 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.
* 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.
Whew! Ok. Time for more coffee :)
-Chris
"Chris Weyl" cweyl@alumni.drew.edu 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
On 5/18/07, Robin Norwood rnorwood@redhat.com wrote:
"Chris Weyl" cweyl@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
On Fri, 2007-05-18 at 14:33 -0400, Robin Norwood wrote:
"Chris Weyl" cweyl@alumni.drew.edu 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 -
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 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.
Now, I can only urge you to revert your recent changes for rawhide (F8) ASAP.
- 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 ...
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.
Steven Pritchard has/had a couple of nice scripts.
- 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).
- 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.
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.
- 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).
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".
Ralf
Ralf Corsepius rc040203@freenet.de writes:
On Fri, 2007-05-18 at 14:33 -0400, Robin Norwood wrote:
"Chris Weyl" cweyl@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
On Sat, 2007-05-19 at 16:04 -0400, Robin Norwood wrote:
Ralf Corsepius rc040203@freenet.de writes:
On Fri, 2007-05-18 at 14:33 -0400, Robin Norwood wrote:
"Chris Weyl" cweyl@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.
You have effectively reverted the split.
The changes were to make the perl-devel require the other split modules, and include the split modules in the default install.
Exactly this is the reversion - Forcing "module'ed" BR's and R's to gain long term packaging stability was one of the prime objectives.
Now, you're allowing people to continue their sloppy (bad) habits.
- 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?
You aren't subscribed to maintainers@? Then you'd better be.
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!
OSS development is based on "give and take" ... You will have to understand that such lonesome and lately communicated decisions drive external volunteers away.
- 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.
There likely are more modules which would make sense to be split out, but a "split out everything" would be stupid.
What I think the next steps should be 1. Revert your recent changes 2. Reconsider the *-lib split. 3. Reflect this split to perl-modules. .. n. Check for further split-out candidates.
Ralf
perl-devel@lists.fedoraproject.org