Re: Give up your modules!
- Original Message From: Jonathan Rockway [EMAIL PROTECTED] To: James E Keenan [EMAIL PROTECTED] Cc: module-authors@perl.org; Ovid [EMAIL PROTECTED] Sent: Tuesday, August 15, 2006 12:50:47 AM Subject: Re: Give up your modules! Is there software that needs to be written? I could write a small Catalyst application to handle this, if someone is willing to host it. I suspect this isn't what you were talking about, but we could also assign weights to various components: 1. The number of bug reports and their severity. 2. Number of days since last release. 3. The number of CPAN tester reports (total, separating test failures is useless since those are mostly a waste of time) 4. The number of other modules which have a dependency on the current module. Multiply each number by its weight and sum them. Skip if no bugs are in RT (or multiply the first result by the next 3?) Thus, a module with a severe bug but no tester reports and no other modules requiring it would probably not show up. A module with 3 severe bugs, hasn't been updated in 7 months, has over 50 CPAN tester reports and is widely used as a dependency is going to shoot near the top of the list. 3. (And this is the delicate part ...) A way to encourage authors/maintainers whose code needs transfer to a new maintainer to effect that. The scheme I mention above might help. It also might get a lynch mob showing up at my door. Nothing wrong with a good-old-fashion hostile fork now and again :) But hopefully we can avoid that. I'd almost be inclined to have takeovers than forks, but I suspect I'll be universally shouted down over that one. If module authors are unwilling to fix bugs in critical proojects and not allow comaintainers, the poor end-user is stuck. When working on large projects, it's usually far easier to get approval to upgrade a module than to change it (not to mention the fact that the work is easier, too). I completely realize that maintaining a lot of CPAN modules can be difficult at times. We have up times where we get a lot of stuff done and down times where we need to relax. That's OK. But not giving users a way out when they encounter problems just isn't fair. Why are we clinging to those modules if we're not going to fix them? More than once places I've worked at have vetoed modules because they do everything we want, just the way we want it, but the bugs kill us and the author is unresponsive. Then we have to find an alternative or make one. Cheers, Ovid
Re: Give up your modules!
Ovid [EMAIL PROTECTED] writes: isn't the responsible thing to find a way to get those bug fixes out there? First of all, one needs to know that there are bugs. Currently, only bugs that get reported via RT are automatically transmitted to the author. That's good. But failed CPAN tests are not reported automatically. Neither are discussions on annocpan, ratings.cpan and whatever other web sites or mailing lists. -- Johan
Re: Give up your modules!
Quoting Ovid: Nothing wrong with a good-old-fashion hostile fork now and again :) But hopefully we can avoid that. I'd almost be inclined to have takeovers than forks, but I suspect I'll be universally shouted down over that one. If module authors are unwilling to fix bugs in critical proojects and not allow comaintainers, the poor end-user is stuck. Looking at the recent and past history of the CPAN, I'd say that forks usually happen for young modules with very active development (see the Class::DBI / DBIx::Class case). Mature modules look unsexy to most people's eyes, even to the author's, and he or she is usually quite eager to let someone else deal with the bugfixes. Said in another way, if you feel that there is a number of modules that need a new maintainer while bug are piling up, it's usually not because the author doesn't want to give the co-maintenance, but because nobody wants to deal with such unfun work. Creating a web site which shows the modules in dire need of maintenance is a good thing, but the next question is: how many people here will then accept to maintain such modules? (History has shown that this number is very low.) -- Sébastien Aperghis-Tramoni Close the world, txEn eht nepO.
Re: Give up your modules!
On 8/15/06, Sébastien Aperghis-Tramoni [EMAIL PROTECTED] wrote: Quoting Ovid: Said in another way, if you feel that there is a number of modules that need a new maintainer while bug are piling up, it's usually not because the author doesn't want to give the co-maintenance, but because nobody wants to deal with such unfun work. Creating a web site which shows the modules in dire need of maintenance is a good thing, but the next question is: how many people here will then accept to maintain such modules? (History has shown that this number is very low.) There were quite a number of times I wrote to module authors asking to help with their modules. In many cases I have not heard back from them. As I see most of the modules are usually maintained by one person. It might be better if we could encourage co-maintenance of modules. Even small ones. The infrastructure to allow other people to upload the same module is there. If there are two maintainers it is much morel ikely that when one of them gets busy or tired the other one can still carry on AND find a new co-developer/co-maintainer. I can only describe what I feel: Personally I would not like to pass maintainership to anyone as I am still in the phase of *I want to reinvent that wheel* but I would really like to get some help with both my modules and my applications. I am not sure what would be the a good way to encourage people to cooperate more. Gabor
Re: Give up your modules!
On 8/15/06, Ovid [EMAIL PROTECTED] wrote: - Original Message From: Jonathan Rockway [EMAIL PROTECTED] To: James E Keenan [EMAIL PROTECTED] Cc: module-authors@perl.org; Ovid [EMAIL PROTECTED] Sent: Tuesday, August 15, 2006 12:50:47 AM Subject: Re: Give up your modules! Is there software that needs to be written? I could write a small Catalyst application to handle this, if someone is willing to host it. I suspect this isn't what you were talking about, but we could also assign weights to various components: 1. The number of bug reports and their severity. 2. Number of days since last release. 3. The number of CPAN tester reports (total, separating test failures is useless since those are mostly a waste of time) 4. The number of other modules which have a dependency on the current module. Multiply each number by its weight and sum them. Skip if no bugs are in RT (or multiply the first result by the next 3?) I guess such thing should be part of CPANTS. Gabor
Re: Give up your modules!
Isn't CPANTS down indefinitely? I guess such thing should be part of CPANTS. Gabor
Re: Give up your modules!
- Original Message From: Gabor Szabo [EMAIL PROTECTED] I guess such thing should be part of CPANTS. ++ -- Buy the book -- http://www.oreilly.com/catalog/perlhks/ Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
Re: Give up your modules!
On 8/15/06, Jonathan Rockway [EMAIL PROTECTED] wrote: Isn't CPANTS down indefinitely? It alive and kicking: http://cpants.perl.org/ and I think Thomas Klausner would be glad to see more people hacking on it. Gabor
Re: Give up your modules!
On 8/14/06, James E Keenan [EMAIL PROTECTED] wrote: In the subsequent discussion, people suggested that we need the following: 1. Place for current module authors/maintainers who wish to transfer maintenance of certain modules to so indicate. 2. Place for people who are willing to take over maintenance of CPAN modules to so indicate. 3. (And this is the delicate part ...) A way to encourage authors/maintainers whose code needs transfer to a new maintainer to effect that. My hunch is that if we get (1) and (2) up and working, it will be easier to accomplish (3). jimk Is not this mailing list both 1 and 2? Without some kind of centralized subscription service its difficult to come up with a business case for setting up systems to satisfy the mandate of 3. OTOH, a centralized subscription service that guarantees maintenance and support of modules downloaded therefrom may or may not fly. I don't think it would work; at least not any better than activestate's vetting of what becomes a PPM. -- David L Nicol all your grammar nit are belong to us
