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