RE: Take back your modules! (was: Re: Give up your modules!)

[Orton, Yves]

Title: RE: Take back your modules! (was: Re: Give up your modules!) 





> On Sep 7, 2006, at 9:08 AM, Mark Stosberg wrote:
> 
> > I say: If you are care about a module's maintenance, start 
> acting like
> > you own it, being considering that others, especially the current
> > maintainer, may feel the same way.
> 
> Nice.  Worthy of a use.perl.org post so others can see it.  Maybe  
> perlmonks too.


I heartily concur


Yves

Re: Take back your modules! (was: Re: Give up your modules!)

[Andy Lester]

On Sep 7, 2006, at 9:08 AM, Mark Stosberg wrote:


I say: If you are care about a module's maintenance, start acting like
you own it, being considering that others, especially the current
maintainer, may feel the same way.


Nice.  Worthy of a use.perl.org post so others can see it.  Maybe  
perlmonks too.


--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Take back your modules! (was: Re: Give up your modules!)

[Mark Stosberg]

Ovid wrote:
> Hi all,
> 
> No names, but if you happen to be sitting on a module which other people 
> depend on and you're not going to fix bugs, give up the module, offer someone 
> co-maintainership or figure out *something* which gives users a way out. I 
> realize that not everyone has a pile of free time to constantly upgrade and 
> maintain modules, but if it's something widely used and you don't have time 
> for it, isn't the responsible thing to find a way to get those bug fixes out 
> there? 

I just want to point out that "giving maintainership" involves two
consenting parties, and this a author-centric approach.

The user-centric approach works too.  Leave patches in RT. Follow-up on
the other bug reports until you reach resolution. Leave a note in RT
that says "I recommend this issue be resolved because..."

Go ahead and prepare a next proposed release with tests/docs/code and
ChangeLog updates and tell the author they can simply sign-off on it.

I now help maintain Data::FormValidator, CGI::Session, CGI::Application,
and WWW::Mechanize, none of which I wrote.

In all cases, the existing maintainers have been appreciative of my
pro-active approach.

>From my perspective, there aren't enough users acting like the software
is "theirs". Considering the licenses on CPAN, they have equal right to
work on it. I'm not sure what the hang-ups are for getting users to be
more active, though.

I say: If you are care about a module's maintenance, start acting like
you own it, being considering that others, especially the current
maintainer, may feel the same way.

   Mark

Re: Give up your modules!

[Sam Vilain]

Ken Williams wrote:
> That said, there ought to be a way for the community to move forward
> without having the original author be the bottleneck.  With open-source
> licenses, there's explicitly a way for someone else in the community to
> pick up the reins and release a "derivative" of the original code
> without seeking the permission of the original author: JFDI.  Change the
> namespace if you must.  People will cope, it's better than having no new
> release at all.

You do not even need to change the namespace; if people would like to
show that they are ready to take over a module, there is nothing to stop
them "proving themselves" by just uploading the it to CPAN.  They won't
get indexed (or, in turn, downloaded automatically by the CPAN shell),
but they will still be carried by the CPAN network, and show up on
search.cpan.org.

Then, all you need is a suitably convincing petition of users to have
the namespace handed over, or have the original author approve the
hand-over.

IOW "Show me the code" :)

With Perl 6, and once the core cpan network and installation modules
support this adequately, you even have a workaround; just tell your
users to write;

  use Crypt::Rijndael-(Any)-SCHNEIER;

There will be much more on this topic in the cpan6 announcement talk at
YAPC::Eu in Birmingham.

Sam.

Re: Give up your modules!

[James E Keenan]

David Golden wrote:




I want to endorse imacat on her contributions.  She runs one of the best 
smoke testers on cpan-testers: it's really strict and seems to catch 
lots of people out on subtle dependency problems.  She's also been very 
responsive to questions I've had about failed test reports.  These are 
contributions I value highly.





I second David's remarks.  When I was revising ExtUtils::ModuleMaker at 
this time last year, imacat's tests caught more, and more subtle, 
problems than anyone else's.  And I noted that in a talk I gave several 
times over the last year, including at YAPC in Chicago.


jimk

Re: Give up your modules!

[Ken Williams]

On Aug 24, 2006, at 7:58 AM, Shlomi Fish wrote:

Maybe it would be a good idea to spend some TPF (or whatever)  
grants on giving
bounties for resuming maintenance of several critically  
unmaintained CPAN

modules? With their authors' permissions, of course.


In that case, I think I'll abandon a few of my well-used modules for  
a couple years and then resume them again so I can claim the reward  
money. =)


 -Ken

Re: Smoke (was Re: Give up your modules!)

[Andy Armstrong]

On 24 Aug 2006, at 16:05, imacat wrote:

Hope this helps.  Please tell me if you need any more information.


That's great, thanks - I'll give it a try.

--
Andy Armstrong, hexten.net

Re: Smoke (was Re: Give up your modules!)

[imacat]

On Thu, 24 Aug 2006 14:05:34 +0100
Andy Armstrong <[EMAIL PROTECTED]> wrote:
> On 24 Aug 2006, at 13:59, David Golden wrote:
> What specifically is imacat doing that makes her an example of best  
> practice and how may others do something similar?

This may be off-topic.  I do not know what is "best practice", but
this is my configuration.  It's a result of my repeatly experiment on
the issues I encountered.  There may still be improvement.

The commented "force" issue is already submitted to rt.cpan.org is
dealed.  It will be fixed in the next release of CPANPLUS.

http://rt.cpan.org/Ticket/Display.html?id=20640

Thanks to Robert Rothenberg on his CPAN-YACSmoke.  But it's a little
tricky to tweak the CPANPLUS::Configure instance used by CPAN::YACSmoke. 
This is not documented.  From peeping into the code there are 2
instances of CPANPLUS::Configure inside.  Both are effective.  Robert
may not be aware that someone might try to alter CPANPLUS::Configure
after initializing the CPAN::YACSmoke object.

Hope this helps.  Please tell me if you need any more information.

===
$smoke = new CPAN::YACSmoke;
# No storable -- always test packages, no matter tested before or not
$smoke->{"conf"}->set_conf("storable", 0);
$smoke->{"cpan"}->configure_object->set_conf("storable", 0);
# Force test even if been tested
# See CPANPLUS::Dist::MM.  "force" make test always passed
#$smoke->{"force"} = 1;
#$smoke->{"conf"}->set_conf("force", 1);
#$smoke->{"cpan"}->configure_object->set_conf("force", 1);
# Send the test result
$smoke->{"cpantest"} = 1;
$smoke->{"conf"}->set_conf("cpantest", 1);
$smoke->{"cpan"}->configure_object->set_conf("cpantest", 1);
# Follow the prerequisites automatically
$smoke->{"prereqs"} = 1;
$smoke->{"conf"}->set_conf("prereqs", 1);
$smoke->{"cpan"}->configure_object->set_conf("prereqs", 1);
# Be verbose
$smoke->{"verbose"} = 1;
$smoke->{"conf"}->set_conf("verbose", 1);
$smoke->{"cpan"}->configure_object->set_conf("verbose", 1);
# Use http://www.cpan.org/ as source
$smoke->{"conf"}->set_conf("hosts", [{
'host' => 'www.cpan.org',
'path' => '/',
'scheme' => 'http'
}]);
$smoke->{"cpan"}->configure_object->set_conf("hosts", [{
'host' => 'www.cpan.org',
'path' => '/',
'scheme' => 'http'
}]);
==

--
Best regards,
imacat ^_*' <[EMAIL PROTECTED]>
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

<> News: http://www.wov.idv.tw/
Tavern IMACAT's: http://www.imacat.idv.tw/
TLUG List Manager: http://lists.linux.org.tw/cgi-bin/mailman/listinfo/tlug


pgpDSDIxfvIlu.pgp
Description: PGP signature

Re: Smoke (was Re: Give up your modules!)

[Andy Armstrong]

On 24 Aug 2006, at 14:13, David Golden wrote:
She would have to answer that definitively, but from what I can  
tell, it looks like she might be using an isolated, fresh perl  
installation (that isn't even in the $PATH) that gets reset after  
each smoke.  From test reports I've seen, it looks like the whole  
non-core prerequisite chain gets installed from scratch for each  
module tested.


Ah right; that makes sense, thanks. I've got snapshots of out-of-the- 
box 5.8.8 and 5.9.4 installs that I use for testing locally - I'll  
have a look at hooking that up to smoke.


Cheers :)

--
Andy Armstrong, hexten.net

Re: Smoke (was Re: Give up your modules!)

[David Golden]

Andy Armstrong wrote:
What specifically is imacat doing that makes her an example of best 
practice and how may others do something similar?


She would have to answer that definitively, but from what I can tell, it 
looks like she might be using an isolated, fresh perl installation (that 
isn't even in the $PATH) that gets reset after each smoke.  From test 
reports I've seen, it looks like the whole non-core prerequisite chain 
gets installed from scratch for each module tested.


Regards,
David

Smoke (was Re: Give up your modules!)

[Andy Armstrong]

On 24 Aug 2006, at 13:59, David Golden wrote:
I want to endorse imacat on her contributions.  She runs one of the  
best smoke testers on cpan-testers: it's really strict and seems to  
catch lots of people out on subtle dependency problems.  She's also  
been very responsive to questions I've had about failed test  
reports.  These are contributions I value highly.


That reminds me of something I've been meaning to investigate - is  
there a guide anywhere or a starting point about running smoke.


I'm running smoke on two machines here - but they're both out of the  
box setups and I'd like to provide more benefit if possible.


What specifically is imacat doing that makes her an example of best  
practice and how may others do something similar?


--
Andy Armstrong, hexten.net

Re: Give up your modules!

[Shlomi Fish]

On Thursday 24 August 2006 15:43, Dana Hudes wrote:
> Just because I haven't had time to update Net::Whois in years doesn't
> mean I haven't got plans or indeed scraps of code. It actually is an
> interesting case because its really a wrapper around external service
> which refuses to standardize (despite efforts toward that) and changes
> willy-nilly. It needs a complete rewrite to address the needs of today's
> registrar lookups. I don't have time for it but I have plans for it. I
> have had someone try to steal the maintainership out from under me. That
> wasn't nice. Especially since his fixes didn't solve the underlying
> issues. I believe he took my code, which in turn was based on Chip's
> original version, and eventually made a new module with documentation
> excoriating me for not letting him take  Net::Whois away from me (around
> this same time, I was a p/t college professor and had a research student
> working to implement my plans for a new version so you can imagine I was
> really rather annoyed at the hijack attempt).  This hijacker actually
> lied to the CPAN librarian saying that I had approved this transfer.
> fortunately, I got a notice of the change and protested and it was
> reversed.
>
> Recently, someone proposed to co-maintain and I have asked him to send
> me a development plan of some kind outlining what it is that he wants to
> do. He agreed that this was a reasonable approach but has never gotten
> back to me with the plan. Finding a new maintainer isn't as easy as it
> sounds we are all busy. then of course there are people outside the
> module author community who, despite using free software, see no reason
> to spend any of THEIR time contributing back to the community with
> actual code. Instead they go on about how its great to get this stuff
> for free -- as in $0 -- and that's it.
>
> Best way to get a maintainer to resume interest is to address
> motivation. Monetary support makes time available if the maintainer has
> any interest in the topic. 

Maybe it would be a good idea to spend some TPF (or whatever) grants on giving 
bounties for resuming maintenance of several critically unmaintained CPAN 
modules? With their authors' permissions, of course.

Well, at least XML::LibXML is maintained again. :-)

In any case, I should note that I'm aware of one important module which has 
over 20 pending bugs in rt.cpan.org (one of them with a patch by me, and 
probably others with patches), whose author refuses to take the time to close 
the bugs. (And yes, he's still alive.). If these bugs are not real, they 
should still be closed, and several of them are in fact real.

Regards,

Shlomi Fish

-
Shlomi Fish  [EMAIL PROTECTED]
Homepage:http://www.shlomifish.org/

Chuck Norris wrote a complete Perl 6 implementation in a day but then
destroyed all evidence with his bare hands, so no one will know his secrets.

Re: Give up your modules!

[David Golden]

imacat wrote:

On Thu, 24 Aug 2006 09:46:33 +0100
Oh I see.  You may not know me.  I personally have submit numerous
patches, bug reports, tests reports, debug reports to numerous packages,
perl modules or not.  You may not know how much time I have spent on
submitting patches and bug reports to all kinds of free software
packages only in 2006.  There are still 10+ bug reports by me hanging on
rt.  Unlike most CPAN tester robots, I even take time on modules that
hang in their test suite and hence did not sent any test report, and
report them manually, even that I'm not using them at all.  I did what I
can as best as possible, to help the community.  I may not be famous,
might not be widely known due to not showing up on meetings all over the
world, for I'm not that rich, but I'm not that kind of stupid and greedy
newbie you described so ugly.


I want to endorse imacat on her contributions.  She runs one of the best 
smoke testers on cpan-testers: it's really strict and seems to catch 
lots of people out on subtle dependency problems.  She's also been very 
responsive to questions I've had about failed test reports.  These are 
contributions I value highly.


Regards,
David Golden

Re: Give up your modules!

[Dana Hudes]

Just because I haven't had time to update Net::Whois in years doesn't 
mean I haven't got plans or indeed scraps of code. It actually is an 
interesting case because its really a wrapper around external service 
which refuses to standardize (despite efforts toward that) and changes 
willy-nilly. It needs a complete rewrite to address the needs of today's 
registrar lookups. I don't have time for it but I have plans for it. I 
have had someone try to steal the maintainership out from under me. That 
wasn't nice. Especially since his fixes didn't solve the underlying 
issues. I believe he took my code, which in turn was based on Chip's 
original version, and eventually made a new module with documentation 
excoriating me for not letting him take  Net::Whois away from me (around 
this same time, I was a p/t college professor and had a research student 
working to implement my plans for a new version so you can imagine I was 
really rather annoyed at the hijack attempt).  This hijacker actually 
lied to the CPAN librarian saying that I had approved this transfer. 
fortunately, I got a notice of the change and protested and it was reversed.


Recently, someone proposed to co-maintain and I have asked him to send 
me a development plan of some kind outlining what it is that he wants to 
do. He agreed that this was a reasonable approach but has never gotten 
back to me with the plan. Finding a new maintainer isn't as easy as it 
sounds we are all busy. then of course there are people outside the 
module author community who, despite using free software, see no reason 
to spend any of THEIR time contributing back to the community with 
actual code. Instead they go on about how its great to get this stuff 
for free -- as in $0 -- and that's it.


Best way to get a maintainer to resume interest is to address 
motivation. Monetary support makes time available if the maintainer has 
any interest in the topic. I personally would have been pleased to spend 
3 months making the ultimate WHOIS lookup system. Don't have the time. I 
do need to come back to it because my other ideas need it...but I don't 
have time to work on them either. got to pay the bills



Ken Williams wrote:


On Aug 24, 2006, at 4:31 AM, Ovid wrote:


- Original Message 
From: Ken Williams <[EMAIL PROTECTED]>


Having a "name and shame" mentality about this is IMO wrong.


I hope you're not saying I suggested that.  I did not name anyone.  I 
didn't ask for a list of modules whose authors we should hunt down.


That's true, it's more the "shame" part I'm objecting to, and I 
latched on to that meme from somewhere out in pop culture.




I only asked for those authors to find *some* way of ensuring that 
their users can get support if the author does not have the time or 
inclination to do so.


I guess that's true, but I bet those authors aren't going to be 
reading the module-authors list much either.


 -Ken

Re: Give up your modules!

[Ken Williams]

On Aug 24, 2006, at 4:31 AM, Ovid wrote:


- Original Message 
From: Ken Williams <[EMAIL PROTECTED]>


Having a "name and shame" mentality about this is IMO wrong.


I hope you're not saying I suggested that.  I did not name anyone.   
I didn't ask for a list of modules whose authors we should hunt down.


That's true, it's more the "shame" part I'm objecting to, and I  
latched on to that meme from somewhere out in pop culture.




I only asked for those authors to find *some* way of ensuring that  
their users can get support if the author does not have the time or  
inclination to do so.


I guess that's true, but I bet those authors aren't going to be  
reading the module-authors list much either.


 -Ken

Re: Give up your modules!

[Andy Armstrong]

On 24 Aug 2006, at 08:33, Andreas J. Koenig wrote:

That's what the DSLIP status already knows as

S (Support Level): a (abandoned)


I guess the problem is that there's not a pervasive culture of people  
setting their modules to abandoned when they decide to abandon them.


I imagine that a lot of time can pass between someone maintaining a  
module for the last time and eventually deciding that they aren't  
supporting it - human nature being what it is.


--
Andy Armstrong, hexten.net

Re: Give up your modules!

[Nicholas Clark]

On Thu, Aug 24, 2006 at 06:46:56PM +0800, imacat wrote:

> Oh I see.  You may not know me.  I personally have submit numerous
> patches, bug reports, tests reports, debug reports to numerous packages,
> perl modules or not.  You may not know how much time I have spent on
> submitting patches and bug reports to all kinds of free software
> packages only in 2006.  There are still 10+ bug reports by me hanging on

No, I admit that I don't. Many people do not know how much of my time I
have volunteered to Perl in 2006 alone. Most people take it for granted.
Hence I am a troubled whenever I see requests for help from people whom I
don't recognise.

> world, for I'm not that rich, but I'm not that kind of stupid and greedy
> newbie you described so ugly.

I'm sorry for mistaking you as one.

> But for this issue, I really have 3 choices:

> 2. Address this issue to the public and see if someone encounter the
> same problem with the same modules and see what we can do.

> I choose 2.  2 is the most reasonable and positive choise to me
> currently.  Any problem?

No, none, given that I now know that you had considered the other choices.
Sadly few people seem to.

But please don't be surprised or disheartened if you receive no response.

Nicholas Clark

Re: Give up your modules!

[Andy Armstrong]

On 24 Aug 2006, at 08:09, Johan Vromans wrote:

Maybe it is just a little thing, but it might be a small step forward:
how about adding a CPAN flag indicating the author has given up
interest in maintaining a specific module? This makes it easy for an
author to formally give up a module, without having to find a new
maintainer first, which may be a tedious process. Should, in some
later stage, anyone be interested in taking over maintainenance she is
free to do so.


I'm trying to track down an author at the moment who I'm fairly sure  
has abandoned the module in question. A mechanism like that would be  
a huge help to me.


If something like that existed it'd be useful also to be able to get  
a list of all the abandoned modules.


--
Andy Armstrong, hexten.net

Re: Give up your modules!

[imacat]

On Thu, 24 Aug 2006 09:46:33 +0100
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 23, 2006 at 06:52:26PM +0800, imacat wrote:
> > I'm not a skilled C/XS programmer, or I would consider taking over
> > them.  Can anybody have advice on this issue?
> The author made these modules available to you for free.
> So any support you get is a bonus. 
> You seem to be assuming that someone owes you a fix for these modules.
> For free.

Oh I see.  You may not know me.  I personally have submit numerous
patches, bug reports, tests reports, debug reports to numerous packages,
perl modules or not.  You may not know how much time I have spent on
submitting patches and bug reports to all kinds of free software
packages only in 2006.  There are still 10+ bug reports by me hanging on
rt.  Unlike most CPAN tester robots, I even take time on modules that
hang in their test suite and hence did not sent any test report, and
report them manually, even that I'm not using them at all.  I did what I
can as best as possible, to help the community.  I may not be famous,
might not be widely known due to not showing up on meetings all over the
world, for I'm not that rich, but I'm not that kind of stupid and greedy
newbie you described so ugly.

But for this issue, I really have 3 choices:

1. Ignoring it, and nobody in the whole world will know.  After all, I
can disable that part of code that uses Crypt-Cracklib, and
Crypt-Rijndael has a non-perfect replacement.  I can write a whole
content management system with a million lines from nothing.  What's so
hard to merely disable using a module?

2. Address this issue to the public and see if someone encounter the
same problem with the same modules and see what we can do.

3. Drop my current schedule, my job and my school and jump into the
world of C/XS, and die for no income to pay my dinner and bill and rent.

I choose 2.  2 is the most reasonable and positive choise to me
currently.  Any problem?

-- 
imacat ^_*'
[EMAIL PROTECTED]
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

Tavern IMACAT's http://www.imacat.idv.tw/
Woman's Voice http://www.wov.idv.tw/
TLUG List Manager http://www.linux.org.tw/mailman/listinfo/tlug


pgpwVfQniO5W3.pgp
Description: PGP signature

Re: Give up your modules!

[Ovid]

- Original Message 
From: Ken Williams <[EMAIL PROTECTED]>

> Having a "name and shame" mentality about this is IMO wrong.

I hope you're not saying I suggested that.  I did not name anyone.  I didn't 
ask for a list of modules whose authors we should hunt down.

I only asked for those authors to find *some* way of ensuring that their users 
can get support if the author does not have the time or inclination to do so.  
It's not too hard to find widely used modules which for various reasons, would 
be hard to switch away from yet are effectively abandoned (which is as close as 
I'll come to naming and shaming).  That list should be left as a *private* 
exercise for the reader.

Cheers,
Ovid

Re: Give up your modules!

[Andreas J. Koenig]

> On Thu, 24 Aug 2006 09:41:31 +0200, Johan Vromans <[EMAIL PROTECTED]> 
> said:

  > [EMAIL PROTECTED] (Andreas J. Koenig) writes:
 >> That's what the DSLIP status already knows as
 >> 
 >> S (Support Level): a (abandoned)

  > Yes, but instead of "abandoned" I was thinking of "scheduled to be
  > abandoned", where the original DSLIP flag still has value.

  > Maybe this is a bit too much of fine-tuning...

I'd think so.

  > How many modules are actually marked "abandoned"?

mysql> select modid,userid from mods where stats='a' and mlstatus='list' ;
+---+--+
| modid | userid   |
+---+--+
| Agent | SPURKIS  |
| Quiz::Question| RFOLEY   |
| Unix::UserAdmin   | JZAWODNY |
| Be::Query | TSPIN|
| Image::ParseGIF   | BENL |
| Perlbug   | RFOLEY   |
| SimpleCDB | BENL |
| Module::MakefilePL::Parse | RRWO |
| Win32::Share  | MNIKHIL  |
| Mozilla::Backup   | RRWO |
| Lingua::EL::Poly2Mono | SPROUT   |
+---+--+
11 rows in set (0.00 sec)


-- 
andreas

Re: Give up your modules!

[Nicholas Clark]

On Thu, Aug 24, 2006 at 03:16:22PM +0800, imacat wrote:
> On Wed, 23 Aug 2006 14:28:13 +0100
> Nicholas Clark <[EMAIL PROTECTED]> wrote:
> > On Wed, Aug 23, 2006 at 06:52:26PM +0800, imacat wrote:
> > > But this ain't right.  Crypt-Cracklib is critical to security and
> > > user management, Crypt-Rijndael is the current US governmental standard
> > > encryption algorithm, and x86_64 is the contemporary architech.  It's
> > > just not right that they don't work.
> > What would you consider to be the "right" that should be happening here?
> > Answering that will make answering your next question easier:
> 
> "Working".  Sorry, but I don't get the point of your question.

Thanks. See below:

On Wed, Aug 23, 2006 at 06:52:26PM +0800, imacat wrote:

> I'm not a skilled C/XS programmer, or I would consider taking over
> them.  Can anybody have advice on this issue?

The author made these modules available to you for free.
So any support you get is a bonus. 

In addition, the author has made the source code available to you for free.
This means that you are not reliant on him/her for support - you have more
options:

* Fix the modules yourself
* Employ someone to fix the modules for you


Given that you have said that you do not currently have the skills to fix
these modules, your choices seem to be learn the skills, or employ someone.

You seem to be assuming that someone owes you a fix for these modules.
For free.

I'm not sure why you are assuming this.

This is why I asked you what was not "right". From your answer what seems to
be not "right" is the modules do not continue to be maintained for free in
perpetuity.

Nicholas Clark

Re: Give up your modules!

[Johan Vromans]

[EMAIL PROTECTED] (Andreas J. Koenig) writes:

> That's what the DSLIP status already knows as
>
> S (Support Level): a (abandoned)

Yes, but instead of "abandoned" I was thinking of "scheduled to be
abandoned", where the original DSLIP flag still has value.

Maybe this is a bit too much of fine-tuning...

How many modules are actually marked "abandoned"?

-- Johan

Re: Give up your modules!

[Andreas J. Koenig]

> On Thu, 24 Aug 2006 09:09:55 +0200, Johan Vromans <[EMAIL PROTECTED]> 
> said:

 >> That said, there ought to be a way for the community to move forward
 >> without having the original author be the bottleneck.

  > Maybe it is just a little thing, but it might be a small step forward:
  > how about adding a CPAN flag indicating the author has given up
  > interest in maintaining a specific module? This makes it easy for an
  > author to formally give up a module, without having to find a new
  > maintainer first, which may be a tedious process. Should, in some
  > later stage, anyone be interested in taking over maintainenance she is
  > free to do so.

That's what the DSLIP status already knows as

S (Support Level): a (abandoned)

-- 
andreas

Re: Give up your modules!

[imacat]

On Wed, 23 Aug 2006 14:28:13 +0100
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 23, 2006 at 06:52:26PM +0800, imacat wrote:
> > But this ain't right.  Crypt-Cracklib is critical to security and
> > user management, Crypt-Rijndael is the current US governmental standard
> > encryption algorithm, and x86_64 is the contemporary architech.  It's
> > just not right that they don't work.
> What would you consider to be the "right" that should be happening here?
> Answering that will make answering your next question easier:

"Working".  Sorry, but I don't get the point of your question.

-- 
imacat ^_*'
[EMAIL PROTECTED]
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

Tavern IMACAT's http://www.imacat.idv.tw/
Woman's Voice http://www.wov.idv.tw/
TLUG List Manager http://www.linux.org.tw/mailman/listinfo/tlug


pgpuBmxdIZBsk.pgp
Description: PGP signature

Re: Give up your modules!

[Johan Vromans]

Ken Williams <[EMAIL PROTECTED]> writes:

> The fact that they made their contribution in the first place, and
> people found it useful, seems like it should be honored rather than
> vilified.

I agree fully.

> That said, there ought to be a way for the community to move forward
> without having the original author be the bottleneck.

Maybe it is just a little thing, but it might be a small step forward:
how about adding a CPAN flag indicating the author has given up
interest in maintaining a specific module? This makes it easy for an
author to formally give up a module, without having to find a new
maintainer first, which may be a tedious process. Should, in some
later stage, anyone be interested in taking over maintainenance she is
free to do so.

-- Johan

Re: Give up your modules!

[Ken Williams]

On Aug 23, 2006, at 5:52 AM, imacat wrote:

Ovid <[EMAIL PROTECTED]> wrote:

No names, but if you happen to be sitting on a module which other  
people depend on and you're not going to fix bugs, give up the  
module, offer someone co-maintainership or figure out *something*  
which gives users a way out. I realize that not everyone has a  
pile of free time to constantly upgrade and maintain modules, but  
if it's something widely used and you don't have time for it,  
isn't the responsible thing to find a way to get those bug fixes  
out there?


Maybe I'm in the minority here, but I think the author has the  
prerogative to lose interest, or die, or run out of time, or  
whatever, without being branded as evil by the community.  The fact  
that they made their contribution in the first place, and people  
found it useful, seems like it should be honored rather than vilified.


That said, there ought to be a way for the community to move forward  
without having the original author be the bottleneck.  With open- 
source licenses, there's explicitly a way for someone else in the  
community to pick up the reins and release a "derivative" of the  
original code without seeking the permission of the original author:  
JFDI.  Change the namespace if you must.  People will cope, it's  
better than having no new release at all.


Having a "name and shame" mentality about this is IMO wrong.  Having  
old dead code out there with no recent releases is as much the fault  
of the community as it is of the original author - the one person in  
the scenario who actually released code.




But this ain't right.  Crypt-Cracklib is critical to security and
user management, Crypt-Rijndael is the current US governmental  
standard

encryption algorithm, and x86_64 is the contemporary architech.  It's
just not right that they don't work.

I'm not a skilled C/XS programmer, or I would consider taking over
them.  Can anybody have advice on this issue?



Yeah: find a skilled C/XS programmer and fix it.  What other solution  
could there possibly be?


If the maintainers are as unresponsive as you seem to be saying,  
consider them dead.  They may even *be* dead.  But their code should  
serve as a damn good blueprint for you to get something working.


 -Ken

Re: Give up your modules!

[Nicholas Clark]

On Wed, Aug 23, 2006 at 06:52:26PM +0800, imacat wrote:

> But this ain't right.  Crypt-Cracklib is critical to security and
> user management, Crypt-Rijndael is the current US governmental standard
> encryption algorithm, and x86_64 is the contemporary architech.  It's
> just not right that they don't work.

What would you consider to be the "right" that should be happening here?

Answering that will make answering your next question easier:

> I'm not a skilled C/XS programmer, or I would consider taking over
> them.  Can anybody have advice on this issue?


Nicholas Clark

Re: Give up your modules!

[Ovid]

- Original Message 
From: imacat <[EMAIL PROTECTED]>

> On Mon, 14 Aug 2006 09:19:15 -0500
> Andy Lester <[EMAIL PROTECTED]> wrote:
> > (Re-making my mental note to transcribe "Stop saying 'script'")
>
>Sorry I might be off-topic, but why "Stop saying 'script'"?  I have
> searched the google and found nothing on this.  I thought "script" is
> the formal term to referring them from the beginning, and throughout my
> documentation.  If someone could provide more information or relative
> resources on this issue, I would be very appreciated.

Because Perl programs are programs.  I get tired of people dismissing what I do 
for a living as 'mere scripting' even though there's a darn good chance I've 
worked on systems (in Perl) far larger than many which they have.  By referring 
to Perl programs as scripts, even if they're short programs, we reinforce the 
false notion that Perl is some toy language.

Heck, if I found out a C programmer hacked out a quick 50 line program to solve 
a problem, should I just dismiss that program as a script?

Cheers,
Ovid
 
-- 
Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/

Re: Give up your modules!

[imacat]

On Mon, 14 Aug 2006 03:40:02 -0700 (PDT)
Ovid <[EMAIL PROTECTED]> wrote:
> No names, but if you happen to be sitting on a module which other people 
> depend on and you're not going to fix bugs, give up the module, offer someone 
> co-maintainership or figure out *something* which gives users a way out. I 
> realize that not everyone has a pile of free time to constantly upgrade and 
> maintain modules, but if it's something widely used and you don't have time 
> for it, isn't the responsible thing to find a way to get those bug fixes out 
> there? 
> Cheers,

In fact, there are 2 modules that frustrats me from not maintaining
for a long time:

Dan Sully  Crypt-Cracklib  0.01  since 1998-11-27
http://search.cpan.org/dist/Crypt-Cracklib/
Rafael R. Sevilla  Crypt-Rijndael  0.05  since 2001-09-17
http://search.cpan.org/dist/Crypt-Rijndael/

I was using them on my web system.  Earlier this year I upgraded my
system into x86_64, and they are not working anymore.  I have
submitted failed test reports, rt bug reports, and personal mails, but
no response since.  I even wonder whether their registered e-mail
addresses are still reachable.

For Crypt-Rijndael, I can use Crypt-Rijndael_PP instead.  But for
Crypt-Cracklib I have completely no idea but to disable that part of my
code.  Consider the fact that it is not updated for 8 years!

But this ain't right.  Crypt-Cracklib is critical to security and
user management, Crypt-Rijndael is the current US governmental standard
encryption algorithm, and x86_64 is the contemporary architech.  It's
just not right that they don't work.

I'm not a skilled C/XS programmer, or I would consider taking over
them.  Can anybody have advice on this issue?

-- 
imacat ^_*'
[EMAIL PROTECTED]
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

Tavern IMACAT's http://www.imacat.idv.tw/
Woman's Voice http://www.wov.idv.tw/
TLUG List Manager http://www.linux.org.tw/mailman/listinfo/tlug


pgpF7OehoqhCj.pgp
Description: PGP signature

Re: Give up your modules!

[imacat]

On Mon, 14 Aug 2006 09:19:15 -0500
Andy Lester <[EMAIL PROTECTED]> wrote:
> (Re-making my mental note to transcribe "Stop saying 'script'")

Sorry I might be off-topic, but why "Stop saying 'script'"?  I have
searched the google and found nothing on this.  I thought "script" is
the formal term to referring them from the beginning, and throughout my
documentation.  If someone could provide more information or relative
resources on this issue, I would be very appreciated.

-- 
imacat ^_*'
[EMAIL PROTECTED]
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

Tavern IMACAT's http://www.imacat.idv.tw/
Woman's Voice http://www.wov.idv.tw/
TLUG List Manager http://www.linux.org.tw/mailman/listinfo/tlug


pgpqlxrYBe0Sv.pgp
Description: PGP signature

Re: Give up your modules!

[Adrian Howard]

On 15 Aug 2006, at 21:35, A. Pagaltzis wrote:


* Sébastien Aperghis-Tramoni <[EMAIL PROTECTED]> [2006-08-15 12:40]:

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


Just to clarify this point, DBIx::Class is *not* a fork of
Class::DBI *at all*.


Neither is Class::DBI young (at least not by my definitions :-)

Adrian

Re: Give up your modules!

[fluffy]

Okay, I'll stand up: my modules have been neglected.  FWIW, the deciding
moment was becoming a father, but whatever, I no longer have the time to
devote to maintenance.  I wish I did.  And yes, I have been slow to
reply to bugs, etc., and I'm sure there are some outstanding.

I hate to let go, and would like to remain a "consultant" (!), but I'm
willing to hand over my modules; listed below.  Thanks in advance to
anyone willing to take on the burden.

Mx.

Class::MethodMaker
Term::ProgressBar
Archive::Par
CVSUtils
File::Info
Getopt::Plus
Log::Info
Term::ProgressBar
Tie::Proxy::Hash

On Mon, Aug 14, 2006 at 03:40:02AM -0700, Ovid wrote:
> Hi all,
> 
> No names, but if you happen to be sitting on a module which other people 
> depend on and you're not going to fix bugs, give up the module, offer someone 
> co-maintainership or figure out *something* which gives users a way out. I 
> realize that not everyone has a pile of free time to constantly upgrade and 
> maintain modules, but if it's something widely used and you don't have time 
> for it, isn't the responsible thing to find a way to get those bug fixes out 
> there? 
> Cheers,
> Ovid
> 
> -- Buy the book -- http://www.oreilly.com/catalog/perlhks/
> Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
> 
> 
> 

Re: Give up your modules!

[Ovid]

- Original Message 
From: [EMAIL PROTECTED]

> I hate to let go, and would like to remain a "consultant" (!), but I'm
> willing to hand over my modules; listed below.  Thanks in advance to
> anyone willing to take on the burden.

That sounds great.  I'm glad to hear you're willing to do this.  Of course, you 
could always just offer co-maintainership via PAUSE if you don't want to give 
them up completely :)

I know some authors have had a lot of success with similar announcements on 
Perlmonks or even use.perl.

Cheers,
Ovid
 
-- Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/

Re: Give up your modules!

[Smylers]

Johan Vromans writes:

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

Are they all?  I'm pretty sure I've encountered a case of not getting
them for a module I took over maintenance of.  When reporting a bug I
always look at the module's doc and if the maintainer doesn't
specifically mention RT then I instead use the e-mail address he does
provide.

> But failed CPAN tests are not reported automatically.

I think I've had reports from there mailed to me.

> Neither are discussions on annocpan,

That was discussed on this list soon after it launched.  My memory is
that we decided that it was OK for AnnoCpan to alert an author the first
time a comment is made on her module, and then give the option of
subscribing to future alerts.

Smylers

Re: Give up your modules!

[A. Pagaltzis]

* Sébastien Aperghis-Tramoni <[EMAIL PROTECTED]> [2006-08-15 12:40]:
> 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).

Just to clarify this point, DBIx::Class is *not* a fork of
Class::DBI *at all*.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Give up your modules!

[A. Pagaltzis]

* Jonathan Rockway <[EMAIL PROTECTED]> [2006-08-14 22:40]:
> Although, for some reason I doubt that anyone who reads
> module-authors wants to give up their modules :)

You would be surprised. Until you’ve had a bunch of them on your
plate you don’t realise how time-consuming a committment it can
be. I have only gotten an inkling of it so far, but I see where
this is leading.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Give up your modules!

[David Nicol]

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

Re: Give up your modules!

[Gabor Szabo]

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!

[Ovid]

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

[Jonathan Rockway]

Isn't CPANTS down indefinitely?

> I guess such thing should be part of CPANTS.
>
> Gabor

Re: Give up your modules!

[Gabor Szabo]

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!

[Gabor Szabo]

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!

[Sébastien Aperghis-Tramoni]

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!

[Ovid]

- Original Message 
From: Johan Vromans <[EMAIL PROTECTED]>

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

Agreed.  I'm quite happy to say "only RT" issues.  That doesn't change the fact 
there are still plenty of non-wishlist RT items for some popular CPAN modules 
where said module hasn't been touched in months.

That's why we need to encourage authors of those modules to give users a 
lifeline.

Cheers,
Ovid
 
-- Buy the book -- http://www.oreilly.com/catalog/perlhks/
Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/

Re: Give up your modules!

[Johan Vromans]

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!

[Ovid]

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

[Scott Elcomb]

IMO, reply-to-all is an extra step.  Sorry 'bout that.

On 8/14/06, Scott Elcomb <[EMAIL PROTECTED]> wrote:

On 8/14/06, James E Keenan <[EMAIL PROTECTED]> wrote:
> Ovid wrote:
> > Hi all,
> >
> > No names, but if you happen to be sitting on a module which other people 
depend on and you're not going to fix bugs, give up the module, offer someone 
co-maintainership or figure out *something* which gives users a way out. I realize 
that not everyone has a pile of free time to constantly upgrade and maintain modules, 
but if it's something widely used and you don't have time for it, isn't the 
responsible thing to find a way to get those bug fixes out there?
> > Cheers,
> > Ovid
> >
>
> This bears upon issues I discussed in a presentation at YAPC::NA::2006
> in Chicago the month before last
> (http://thenceforward.net/perl/yapc/YAPC-NA-2006/chicago.html).
>
> 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.

Vote:  yeah.

> 2.  Place for people who are willing to take over maintenance of CPAN
> modules to so indicate.

Vote: yeah.

> 3.  (And this is the delicate part ...)  A way to encourage
> authors/maintainers whose code needs transfer to a new maintainer to
> effect that.


Delicate isn't something I'm good at.  Please.

--
Scott Elcomb
http://atomos.sourceforge.net/
http://search.cpan.org/~selcomb/SAL-3.03/
http://psema4.googlepages.com/

"In matters of style, swim with the current; in matters of principle,
stand like a rock."

  - Thomas Jefferson




--
Scott Elcomb
http://atomos.sourceforge.net/
http://search.cpan.org/~selcomb/SAL-3.03/
http://psema4.googlepages.com/

"In matters of style, swim with the current; in matters of principle,
stand like a rock."

 - Thomas Jefferson

Re: Give up your modules!

[Jonathan Rockway]

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.

Regards,
Jonathan Rockway


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

Nothing wrong with a good-old-fashion hostile fork now and again :)  But
hopefully we can avoid that.

Re: Give up your modules!

[James E Keenan]

Ovid wrote:
> Hi all,
> 
> No names, but if you happen to be sitting on a module which other people 
> depend on and you're not going to fix bugs, give up the module, offer someone 
> co-maintainership or figure out *something* which gives users a way out. I 
> realize that not everyone has a pile of free time to constantly upgrade and 
> maintain modules, but if it's something widely used and you don't have time 
> for it, isn't the responsible thing to find a way to get those bug fixes out 
> there? 
> Cheers,
> Ovid
> 

This bears upon issues I discussed in a presentation at YAPC::NA::2006
in Chicago the month before last
(http://thenceforward.net/perl/yapc/YAPC-NA-2006/chicago.html).

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

Re: Give up your modules!

[Jonathan Rockway]

BTW, I have some free time to devote to maintaining modules.  So, if you
want to unload one, let me know.

Although, for some reason I doubt that anyone who reads module-authors
wants to give up their modules :)

Regards,
Jonathan Rockway

Ovid wrote:
> Hi all,
>
> No names, but if you happen to be sitting on a module which other people 
> depend on and you're not going to fix bugs, give up the module, offer someone 
> co-maintainership or figure out *something* which gives users a way out. I 
> realize that not everyone has a pile of free time to constantly upgrade and 
> maintain modules, but if it's something widely used and you don't have time 
> for it, isn't the responsible thing to find a way to get those bug fixes out 
> there? 
> Cheers,
> Ovid
>
> -- Buy the book -- http://www.oreilly.com/catalog/perlhks/
> Perl and CGI -- http://users.easystreet.com/ovid/cgi_course/
>
>   

Re: Give up your modules!

[Eric Wilhelm]

# from Ovid
# on Monday 14 August 2006 03:40 am:

>figure out *something* which gives users a way out.

Maybe if there were a universally accessible subversion repository for 
all of the CPAN?

  http://scratchcomputing.com/developers/svn4cpan/

All we need are some willing victims for a hackfest in Portland.

--Eric
-- 
"...the bourgeoisie were hated from both ends: by the proles, because
they had all the money, and by the intelligentsia, because of their
tendency to spend it on lawn ornaments."
--Neal Stephenson
---
http://scratchcomputing.com
---

Re: Give up your modules!

[Dmitri Tikhonov]

On Mon, 2006-08-14 at 10:18 -0400, Ricardo SIGNES wrote:
> * Gabor Szabo <[EMAIL PROTECTED]> [2006-08-14T07:00:10]
> > e.g. a big red sign on search.cpan.org next to each module that has open 
> > bugs
> > in RT and has not been updated for the past 6 months...
> 
> I use this script to find bugs in mail-handling code or code I maintain.
> 
>   http://rjbs.manxome.org/hacks/perl/bugagg

I'm going to toot my own horn a bit... :) There's a new module that uses
RT's REST interface to query for tickets:

  http://search.cpan.org/dist/RT-Client-REST/

It can also create, modify, resolve, etc.  It's almost beta (meaning
that I will soon freeze the APIs).  If you use it, I'd like some
feedback.

Thanks,

  - Dmitri.

Re: Give up your modules!

[Andy Lester]

On Aug 14, 2006, at 9:18 AM, Ricardo SIGNES wrote:


* Gabor Szabo <[EMAIL PROTECTED]> [2006-08-14T07:00:10]
e.g. a big red sign on search.cpan.org next to each module that  
has open bugs

in RT and has not been updated for the past 6 months...


I use this script to find bugs in mail-handling code or code I  
maintain.


It's a program.

(Re-making my mental note to transcribe "Stop saying 'script'")

xoxo,
Andy

--
Andy Lester => [EMAIL PROTECTED] => www.petdance.com => AIM:petdance

Re: Give up your modules!

[Ricardo SIGNES]

* Gabor Szabo <[EMAIL PROTECTED]> [2006-08-14T07:00:10]
> e.g. a big red sign on search.cpan.org next to each module that has open bugs
> in RT and has not been updated for the past 6 months...

I use this script to find bugs in mail-handling code or code I maintain.

  http://rjbs.manxome.org/hacks/perl/bugagg

-- 
rjbs


signature.asc
Description: Digital signature

Re: Give up your modules!

[Gabor Szabo]

Maybe if there was some alerting system

e.g. a big red sign on search.cpan.org next to each module that has
open bugs in RT
and has not been updated for the past 6 months...

I don't know.

  Gabor