The module authors pledge

4 views
Skip to first unread message

Neil Bowers

unread,
Nov 8, 2011, 11:22:02 AM11/8/11
to module-...@perl.org
One of the problems I see with CPAN is that there are many modules
which have been left unattended. Many of these have outstanding bugs,
and a good number have patches and forked versions, some of which you can
find on RT. You'll also find people offering to take over the maintainership
of modules. While reviewing modules I've identified a lot of fixes, and
documentation improvements, but it can take a lot of effort to get them out.

If the author or current maintainer of a module is unresponsive, there's
a well-defined, but lengthy, process to request co-maintainership.
There are good reasons for this -- I'll assume you've read them.
But in reality, plenty of authors lose interest

To make life easier for the perl modules cabal, how about a voluntary
pledge[*], which module authors can take publically, and in particular
can take to mod...@perl.org. I'll be emailing the following to
mod...@perl.org:

I hereby give mod...@perl.org permission to grant co-maintainership
to any of my modules, if the following conditions are met:

(1) I haven't released the module for a year or more
(2) There are outstanding issues on RT which need addressing
(3) Email to my CPAN email address hasn't been answered after a month
(4) The requester wants to make worthwhile changes that will benefit CPAN

Should I die, then the time-limits in (1) and (3) do not apply.

This means it will be archived, and easily accessed. I'll put this in the
README for my modules.

If others, and particularly the modules cabal, think this is a good idea,
maybe we could have a canonical place this this, which can be easily
referred to. Perhaps PAUSE could let me record it, so there's one place
the modules cabal can check? Or you could put it in module metadata?

So, what do y'all think?

Neil,
in the light of recent discussions, donning flame-retardent long-johns.

[*] I tried to come up with a catchy name for this, but failed. Ideas?

Shmuel Fomberg

unread,
Nov 10, 2011, 4:50:08 AM11/10/11
to Neil Bowers, module-...@perl.org
I am against the 'if I die' part. As we are all communication over the net, it is very difficult to know why a person have stopped responding. 
And it make the statement a bit scary.

Shmuel.

"Burak Gürsoy"

unread,
Nov 10, 2011, 5:17:37 AM11/10/11
to Neil Bowers, module-...@perl.org

-------- Original-Nachricht --------
> Datum: Tue, 8 Nov 2011 16:22:02 +0000
> Von: Neil Bowers <ne...@bowers.com>
> An: module-...@perl.org
> Betreff: The module authors pledge

> One of the problems I see with CPAN is that there are many modules
> which have been left unattended. Many of these have outstanding bugs,
> and a good number have patches and forked versions, some of which you can
> find on RT. You'll also find people offering to take over the
> maintainership

[snip]

Well, there is a good reason with forking modules.
When you push the original author a bit, you can get
an ignorant response [1] Maybe the namespace is so precious
even if the author lost interest.

Or you get no reponse and just want a fixed version anyway.

CPAN: The re-invented and forked Perl wheels repository.

[1]After getting no reponse for a year I spammed the guy on twitter and he replied back: https://rt.cpan.org/Public/Bug/Display.html?id=58570
[2] Will fork it when I have the time for testing it a bit, dodn't bother replying to the ticket and just renamed the repo: https://bitbucket.org/burak/cpan-file-tailx

--
NEU: FreePhone - 0ct/min Handyspartarif mit Geld-zurück-Garantie!
Jetzt informieren: http://www.gmx.net/de/go/freephone

Marco Marongiu

unread,
Nov 10, 2011, 5:17:52 AM11/10/11
to module-...@perl.org
Il 08/11/2011 17:22, Neil Bowers ha scritto:
> Should I die, then the time-limits in (1) and (3) do not apply.

Drop this, as difficult to verify (for various reasons), and +1 from me.

-- bronto

Raphael Mankin

unread,
Nov 10, 2011, 5:22:00 AM11/10/11
to Shmuel Fomberg, Neil Bowers, module-...@perl.org
On Thu, 2011-11-10 at 18:50 +0900, Shmuel Fomberg wrote:
> I am against the 'if I die' part. As we are all communication over the
> net, it is very difficult to know why a person have stopped
> responding.
> And it make the statement a bit scary.
>
The real problem with 'if I die' is that there is no way of knowing: the
only indication one gets is that mail is not being answered, this clause
is therefore pointless. However, having just assumed co-maintainership
of a buggy module, I support the notion - or just make it a condition of
submission to CPAN.
>
[snip]

Boyd Duffee

unread,
Nov 10, 2011, 5:29:09 AM11/10/11
to module-...@perl.org
On 11/08/2011 04:22 PM, Neil Bowers wrote:
> One of the problems I see with CPAN is that there are many modules
> which have been left unattended. Many of these have outstanding bugs,
> and a good number have patches and forked versions, some of which you can
> find on RT. You'll also find people offering to take over the maintainership
> of modules. While reviewing modules I've identified a lot of fixes, and
> documentation improvements, but it can take a lot of effort to get them out.

Being on the patch submitting side of this, I'll put in my 2 pence.

For the last 2 years, I've been bugging one CPAN author to apply my patch
that fixes a bug in RT. He says, "I've moved to GitHub. Fork my project and
issue a pull request". After a while, I learn git issue the pull request and
get on with life. I check back months later to find nothing has changed
because _his_ life has gotten in the way and being a parent myself, I'm
sympathetic. He apologizes and gives me commit access to his repository.
Great, but it _still_ hasn't propagated to CPAN, so when I get around to
fixing the new bug I've found, I'll ask him for co-maintainer status which I
don't expect to be a problem.

In essence, you're trying to elicit from the authors how they feel about
their module, either:
* I'm easy. I just want it to be useful to people.
* That's my _baby_ you're talking about!
which hides the ugly and bureaucratic detail you're rightfully proposing.

<offtopic rant> Github labels itself social coding, yet the 2 projects that
people have suggested I fork see no action on the pull requests and I've gone
out of my way to get my head around Yet Another CVS System just to get the
same result as if I've just emailed a patch. Technology doesn't make people
interested in old projects when there's new shiny to work on.

Or is it me? What's the matter? Do I stink? />

> in the light of recent discussions, donning flame-retardent long-johns.

Perhaps they weren't pleasant for the participants, but I rather enjoyed the
recent discussion. It's been over a decade since I've seen anything so full
of eloquent vitriol, made me hungry for popcorn. Kids these days don't know
how to flame.

> [*] I tried to come up with a catchy name for this, but failed. Ideas?

given the nature of the demographic - The Chastity Pledge?
(tongue firmly in cheek)
--
Boyd

The Kleeberger is defined as a tonne metre per second squared
which you will recognize as a unit of _brute_ force.
http://en.wikipedia.org/wiki/Adam_Kleeberger

David Precious

unread,
Nov 10, 2011, 5:27:56 AM11/10/11
to module-...@perl.org, Shmuel Fomberg, Neil Bowers
On Thursday 10 November 2011 09:50:08 Shmuel Fomberg wrote:
> I am against the 'if I die' part. As we are all communication over the net,
> it is very difficult to know why a person have stopped responding.
> And it make the statement a bit scary.

Hmm - if it's someone reasonably well known in the community, there's a good
chance that someone would know that they'd died. (If nobody knew for sure,
the timeouts in the statements Neil proposed would still turn over control
after a while anyway.)

I'd be happy for my code to be taken over if I've died.

We're looking at our own version of the Organ Donor Register here - Code Donor
Register (CDR)? ;)

Leon Timmermans

unread,
Nov 10, 2011, 7:00:14 AM11/10/11
to Neil Bowers, module-...@perl.org
I've been having the same idea. I'd say the right place is a clearly
named file your CPAN home dir, preferably something explicit and
standardized about when you're ok with it and when not.

Leon

Boyd Duffee

unread,
Nov 10, 2011, 7:09:37 AM11/10/11
to module-...@perl.org
On 11/10/2011 11:11 AM, Neil Bowers wrote:
> If someone comes along and thinks "hey, this would be useful, and I can improve it",
> we should make it easier for the baton to be passed on, as it will improve the overall quality
> of CPAN.
>
> All the while still respecting the original author [1]

My feelings exactly - a tricky balance.

> This pledge is one of the ideas which came from reviewing a bunch of modules,
> which I'm presenting at the London Perl Workshop. You going?

I wanted to, but thesis/life got in the way. They're a great bunch. I was
even at the auction where they decided that meetings would be held on the
Thursday after the first Wednesday of the month. Still makes me smile.


> Code Donor Register (CDR)?

I think David's found the name for when you've moved on. Some people die,
some find a life and for the rest, there's CPAN.

Boyd

Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯

unread,
Nov 10, 2011, 7:32:29 AM11/10/11
to module-...@perl.org
> I've been having the same idea. I'd say the right place is a clearly
> named file your CPAN home dir, preferably something explicit and
> standardized about when you're ok with it and when not.
Metadata can already be attached to distributions in an extensible
fashion. It's really about the code, not the author/maintainer - one
can have different opinions on/policies for different distros.

Ref: CPAN meta spec, channel #toolchain, cpan-workers mailing list
signature.asc

Shawn H Corey

unread,
Nov 10, 2011, 8:33:16 AM11/10/11
to module-...@perl.org
On 11-11-08 11:22 AM, Neil Bowers wrote:
> One of the problems I see with CPAN is that there are many modules
> which have been left unattended. Many of these have outstanding bugs,
> and a good number have patches and forked versions, some of which you can
> find on RT. You'll also find people offering to take over the maintainership
> of modules. While reviewing modules I've identified a lot of fixes, and
> documentation improvements, but it can take a lot of effort to get them out.

That's because CPAN uses old technology. But don't blame it; it was
state of the art when it started.

Convert CPAN to git and all these problems go away. With git, anyone can
fork and improve any module. And if the original author is still
interested, he can merge these improvements back into his copy. The only
problem left is finding the best fork. :)


--
Just my 0.00000002 million dollars worth,
Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

"Make something worthwhile." -- Dear Hunter

Leon Timmermans

unread,
Nov 10, 2011, 9:15:23 AM11/10/11
to Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯, module-...@perl.org
On Thu, Nov 10, 2011 at 1:32 PM, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 <da...@cpan.org> wrote:
> Metadata can already be attached to distributions in an extensible
> fashion. It's really about the code, not the author/maintainer - one
> can have different opinions on/policies for different distros.

True, though most of the time that probably won't be necessary.

Leon

David Cantrell

unread,
Nov 10, 2011, 9:58:23 AM11/10/11
to module-...@perl.org
On Tue, Nov 08, 2011 at 04:22:02PM +0000, Neil Bowers wrote:

> I hereby give mod...@perl.org permission to grant co-maintainership
> to any of my modules, if the following conditions are met:
>
> (1) I haven't released the module for a year or more
> (2) There are outstanding issues on RT which need addressing
> (3) Email to my CPAN email address hasn't been answered after a month
> (4) The requester wants to make worthwhile changes that will benefit CPAN
>
> Should I die, then the time-limits in (1) and (3) do not apply.
>
> So, what do y'all think?

I think that this isn't really different from what happens now anyway.

--
David Cantrell | Reality Engineer, Ministry of Information

Bill Ward

unread,
Nov 10, 2011, 11:10:04 AM11/10/11
to David Cantrell, module-...@perl.org
I think the "Should I die" (though I think "in the event of my death" would be better) can only really work if a family member replies to the email saying that the maintainer has passed away, which isn't too likely but could happen. Since those time limits would expire eventually anyway, it's probably not necessary except that it speeds up the process---*if* you get confirmation of death.
--
Check out my LEGO blog at http://www.brickpile.com
Follow/friend me: facebook.com/billwardflickr.com/photos/billwardtwitter.com/williamward

Yanick Champoux

unread,
Nov 10, 2011, 12:46:12 PM11/10/11
to Neil Bowers, module-...@perl.org
On 11-11-08 11:22 AM, Neil Bowers wrote:
> To make life easier for the perl modules cabal, how about a voluntary
> pledge

Nice idea. I like.

I've been mulling about the same problem in my corner, so here are my 2
canadian cents' worth on the topic:

As I see it, there are two aspects to the problem of orphaned modules.

1. Maintainer has retired / is not interested anymore / has been
abducted by aliens / etc.

Basically, that's the common case where no-one is answering the phone
anymore. To solve this, we need some kind of dead man's switch.

The proposed pledge is one way of doing it. In my afore-mentioned
corner, I was thinking of something quite similar where distributions
would be tagged as orphaned after one year of inactivity, where activity
is defined as (a) release a new version or (b) push a "yeah, yeah, I'm
still here and interested" button somewhere. To be successful, such a
scheme should be careful to let maintainers know (in a non-spammy way)
in advance that their time is running out, to prevent nasty surprises,
and it should be easy and pain-free, even for the maintainers with lots
of distributions.

2. Maintainer wants help

The other case is when a maintainer is still around, but either doesn't
want to maintain a distribution anymore, or wouldn't mind a wee bit of
help. There are been more than a few cases where submitting a patch
resulted in the exchange:

maintainer: Thanks! Hey, I don't really use that module
anymore. Want to be the new maintainer?

me: uh, sure.

maintainer: Tag! You're it!

which, mind you, is awesome. But it would be even awesomer to make the
process a little more proactive and help maintainers to get
replacements. IIRC, PAUSE has an 'orphaned' status for modules, so maybe
the solution could be built on that, but made more public.

Maybe the solution to (1) and (2) lies with a site that would be the
flip side of prepan.org (orPhAN.org ? :-) ), where modules up for
adoption are listed? But Neil brought the crucial point (I think), that
no matter what, the passing of maintainership should never be done
totally automatically, but should always at least get the blessing of
the gardians of mod...@perl.org or the ex-maintainer herself. Just,
y'know, as human sanity check.

Anyway, I could ramble some more, but I better stop before I put
everyone to sleep.

Joy,
`/anick

Neil Bowers

unread,
Nov 10, 2011, 8:34:40 AM11/10/11
to Boyd Duffee, Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯, module-...@perl.org
TL;DR: yeah, what they said.

Boyd wrote:
> In essence, you're trying to elicit from the authors how they feel about
> their module, either:
> * I'm easy. I just want it to be useful to people.
> * That's my _baby_ you're talking about!
> which hides the ugly and bureaucratic detail you're rightfully proposing.

Right now people get fame, glory and rights when they contribute to CPAN.
I think it would help if there was a sense of responsibility as well, and a giving
of some rights.

I get a lot of value out of CPAN, and think of adding modules to the pot as a
way of "giving back", rather than CPAN giving me a distribution channel for my work.

When I upload something to CPAN, I'd almost now like to think that I'm
giving ownership of the module to CPAN, and for the moment I have
stewardship. And as long as I exercise that stewardship, no-one else can take it.

But if other things become important in my life (again!), I don't want to hold
people and CPAN progress up.

And since most CPAN related work is done on a voluntary basis, this cannot
be mandated. But we can encourage the culture to evolve in a certain direction.

Lars wrote:
> Metadata can already be attached to distributions in an extensible
> fashion. It's really about the code, not the author/maintainer - one
> can have different opinions on/policies for different distros.

Absolutely. I might treat one of my distros as my baby, but be a bit
more easy-going on the others. And another might be done for work,
and thus not up for pledging.

Neil

Neil Bowers

unread,
Nov 10, 2011, 5:36:44 AM11/10/11
to Shmuel Fomberg, Raphael Mankin, module-...@perl.org
Shmuel wrote:
> I am against the 'if I die' part. As we are all communication over the net, it is very difficult to know why a person have stopped responding.
> And it make the statement a bit scary.

And Raphael wrote:
> The real problem with 'if I die' is that there is no way of knowing: the
> only indication one gets is that mail is not being answered, this clause
> is therefore pointless.

Having had to deal with this issue for a friend, I'm going to try and put in place mechanisms
so that when my time comes, notifications for stuff like this will happen.

But I accept that most people (a) don't want to think about this sort of thing most of the time,
and (b) it will make this sort of statement less appealing.

Man, you *really* wouldn't have linked one of my earlier drafts! It contained works like
"incapacitated" and "incarcerated" ;-)

I'll mail an updated version once any discussion has calmed down.

Neil

Michael Greb

unread,
Nov 10, 2011, 11:33:16 AM11/10/11
to module-...@perl.org
On Thu, Nov 10, 2011 at 11:10 AM, Bill Ward <bi...@wards.net> wrote:
> I think the "Should I die" (though I think "in the event of my death" would
> be better) can only really work if a family member replies to the email
> saying that the maintainer has passed away, which isn't too likely but could
> happen. Since those time limits would expire eventually anyway, it's
> probably not necessary except that it speeds up the process---*if* you get
> confirmation of death.

My wife has instructions that various aspects of my online life are
delegated to different people in the event of my passing. Perl stuff
goes to a coworker on the periphery of the Perl community that would
be able to easily grant permission for maintainer status to be passed
on.

This works easily as we've talked about it and she has access to my
email but it's the sort of thing that many people don't think to have
the discussion about even when preparing wills and other similar
things.

Neil Bowers

unread,
Nov 10, 2011, 5:41:23 PM11/10/11
to David Cantrell, module-...@perl.org
>> I hereby give mod...@perl.org permission to grant co-maintainership
>> to any of my modules, if the following conditions are met:
>>
>> (1) I haven't released the module for a year or more
>> (2) There are outstanding issues on RT which need addressing
>> (3) Email to my CPAN email address hasn't been answered after a month
>> (4) The requester wants to make worthwhile changes that will benefit CPAN [...]
>
> I think that this isn't really different from what happens now anyway.

I'm interested to hear what you think would make it different?

In my experience this would be different. There's one module that I've been working on
adopting for two months now. I don't want to harrass anyone via email, so I'm gradually
working at it.

Another module I've been working on for about a month, just so I can take upload a
release which resolves a version confusion on CPAN/MetaCPAN, and update the
documentation to say "don't use this module, consider one of these ones ...".
I finally got a response from the original author, to say I can take it over.
I suspect most people wouldn't bother, but it's part of an experiment for me.

I considered making the timeout two weeks rather than a month, but I think we have to
allow for the author being on holiday. To be honest, I'd personally go for something like:

(2) if there are RT issues which have been outstanding for more than 6 months
(3) email to me doesn't get a response within 24 hours

But I suspect many people would find that too aggressive.

Neil

Neil Bowers

unread,
Nov 10, 2011, 6:11:23 AM11/10/11
to Boyd Duffee, module-...@perl.org
Being on the patch submitting side of this, I'll put in my 2 pence.

For the last 2 years, I've been bugging one CPAN author to apply my patch
that fixes a bug in RT.  He says, "I've moved to GitHub.  Fork my project and
issue a pull request".  [...]

I've got a few of those going on.

But in reviewing a bunch of modules recently, I've hit more of the following case:
- no releases in a long time
- I submit things to RT with no response (usually other tickets already there)
- I email the author, and get no response

I've come up with bugs for a number of modules, some of which I'm now going through
the adoption process on, but some I'm figuring it's just not worth it, which is a shame.

Technology doesn't make people interested in old projects when there's new shiny to work on.

Spot on.

If someone comes along and thinks "hey, this would be useful, and I can improve it",
we should make it easier for the baton to be passed on, as it will improve the overall quality
of CPAN.

All the while still respecting the original author [1]
Or is it me?  What's the matter?  Do I stink?

Well, to borrow your phrase, given the demographic, you probably do ;-)

This pledge is one of the ideas which came from reviewing a bunch of modules,
which I'm presenting at the London Perl Workshop. You going?

Neil


[1] I like the statement on respecting the original author in the PAUSE rules:

http://pause.perl.org/pause/query?ACTION=pause_04about

You have to realize that the author has probably invested a signficiant amount of time into writing the code in the first place and then gone through the additional work of making it available to others via CPAN free of charge. Therefore, it is crucial to be very polite when asking him or her for co-maintenance permissions. Politeness, however, does not suffice. Particularly when maintaining a module for which you received co-maintenance permissions from the admins (as opposed to being appointed by the author himself), you are *required* to respect the work and design of the author.

David Cantrell

unread,
Nov 10, 2011, 7:48:18 PM11/10/11
to module-...@perl.org
On Thu, Nov 10, 2011 at 10:41:23PM +0000, Neil Bowers wrote:
> >> I hereby give mod...@perl.org permission to grant co-maintainership
> >> to any of my modules, if the following conditions are met:
> >>
> >> (1) I haven't released the module for a year or more
> >> (2) There are outstanding issues on RT which need addressing
> >> (3) Email to my CPAN email address hasn't been answered after a month
> >> (4) The requester wants to make worthwhile changes that will benefit CPAN [...]
> > I think that this isn't really different from what happens now anyway.
> I'm interested to hear what you think would make it different?

(5) you promise to stuff live octopuses down your pants on stage at the
next YAPC.

> In my experience this would be different.

In general, The Gods seem to let people have a co-maintainer bit if the
primary maintainer is incommunicado - such as not responding for a
month.

--
David Cantrell | top google result for "topless karaoke murders"

In Victorian times, when every man wore a beard the size of a yew,
Britain ruled the world. In the early 20th century, when the beard
was trimmed to a moustache, we scraped through two world wars but
lost an empire. Today, when Mach3 Turbo multi-blades are the norm,
our national pride derives largely from beating the Swedes at
Olympic cycling.

Grow a beard. Your country needs you.

Olaf Alders

unread,
Nov 10, 2011, 8:48:23 PM11/10/11
to Neil Bowers, Shmuel Fomberg, Raphael Mankin, module-...@perl.org

On 2011-11-10, at 5:36 AM, Neil Bowers wrote:

> Shmuel wrote:
>> I am against the 'if I die' part. As we are all communication over the net, it is very difficult to know why a person have stopped responding.
>> And it make the statement a bit scary.
>
> And Raphael wrote:
>> The real problem with 'if I die' is that there is no way of knowing: the
>> only indication one gets is that mail is not being answered, this clause
>> is therefore pointless.
>
> Having had to deal with this issue for a friend, I'm going to try and put in place mechanisms
> so that when my time comes, notifications for stuff like this will happen.

It's not something I had even considered until I happened to take over maintenance of a module whose original author had passed away. So, I can see how it is useful and I would have no issues with including this in my pledge.

Olaf
--
Olaf Alders
ol...@wundersolutions.com

http://www.wundersolutions.com
http://twitter.com/wundercounter

866 503 2204 (Toll free - North America)
416 944 8306 (direct)

David Nicol

unread,
Nov 10, 2011, 10:33:52 PM11/10/11
to Module Authors
To make life easier for the perl modules cabal, how about a voluntary
pledge[*], which module authors can take publically, and in particular
can take to mod...@perl.org. I'll be emailing the following to
mod...@perl.org:

No.
The license chaos is enough as it now is.
 

   I hereby give mod...@perl.org permission to grant co-maintainership
   to any of my modules, if the following conditions are met:

   (1) I haven't released the module for a year or more

Complete modules don't get re-released, so this condition cannot be sufficient on its own ... oh, that doesn't say "any of the..." does it. Sorry.

 
   (2) There are outstanding issues on RT which need addressing
   (3) Email to my CPAN email address hasn't been answered after a month
   (4) The requester wants to make worthwhile changes that will benefit CPAN

So, what do y'all think?

I think this is not necessary at all.  I think you have pretty much described the current standards for granting takeover. I think the barrier to making local forks is already very low and there is no reason to switch the whole thing to Git.

I think CPAN is fine as it is.

--
"One only understands the things that one tames" -- the fox

Todd Rinaldo

unread,
Nov 11, 2011, 9:38:35 AM11/11/11
to Perl Module Authors List

On Nov 10, 2011, at 4:41 PM, Neil Bowers wrote:

>>> I hereby give mod...@perl.org permission to grant co-maintainership
>>> to any of my modules, if the following conditions are met:
>>>
>>> (1) I haven't released the module for a year or more
>>> (2) There are outstanding issues on RT which need addressing
>>> (3) Email to my CPAN email address hasn't been answered after a month
>>> (4) The requester wants to make worthwhile changes that will benefit CPAN [...]
>>
>> I think that this isn't really different from what happens now anyway.
>
> I'm interested to hear what you think would make it different?

I've taken over several modules in the past few years. These are the required steps laid out in the FAQ:

1. Open RT tickets about the issues you are having in the appropriate queue.
-- Normally I just ping an existing RT ticket. Few modules which have not had a release in a few years lack RT tickets.

2. Email the author(s) with as many email addresses as you can determine, cc'ing mod...@cpan.org
-- About 30% of the time, I get a response and resolution with this approach. The biggest problem with this is usually that the address forwarded to by the @cpan.org address bounces. To me, a valid email address in your pause settings is 10x more useful than updating or creating any new meta data.

If I could make any plea to authors, it would be: Module authors, please be sure that you update pause so that your cpan.org address goes somewhere you monitor.

3. Publicly post that you're looking for the author in a frequented blog source
I setup a google blog and have ironman feeding it. I often get helper responses telling me how to find the person. I'll usually do this post the same day I email if it bounces.

The rest is a waiting game. Usually a month. I tend to patch internally, make sure the patch used is in RT. Then ping mod...@cpan.org when the time goes by.

To date, I've had very little issues with the existing process. I don't see how the above manifesto expedites this process:

>>> (1) I haven't released the module for a year or more
I've never had the urge to take on a module being actively maintained, so this isn't really an issue for me. I've got enough work of my own. :)

>>> (2) There are outstanding issues on RT which need addressing
If the modules gone a year or more without any RT tickets, it's a rare module.

>>> (3) Email to my CPAN email address hasn't been answered after a month
This already is part of the existing policy.

>>> (4) The requester wants to make worthwhile changes that will benefit CPAN [...]
That's kinda implied but sure.

My 2 cents.
Todd

John M. Gamble

unread,
Nov 11, 2011, 10:20:34 AM11/11/11
to David Nicol, Module Authors
On 11/10/2011 9:33 PM, David Nicol wrote:
> I think this is not necessary at all. I think you have pretty much
> described the current standards for granting takeover. I think the
> barrier to making local forks is already very low and there is no
> reason to switch the whole thing to Git.
>

Yeah, that was my impression as well. I've observed take-overs here, and
they pretty much are exactly the same procedure -- "Hey, is John
Doe-Smith still working on his modules? No? The can you grant
co-maintenance to Jane Roe-Jones?" (Granted with more-back-and-forth
than that, but it still isn't new.)

Really, the only thing that could help with the current situation is a
direct contact number, and I don't see that happening.

(For what it's worth, having gone through a similar situation when my
mother passed away recently, I'm setting up a list of accounts to be
mailed if I get hit by a bus for my brother and sister, but that's about
the only change I'm making right now.)

> I think CPAN is fine as it is.
>

Oh, I can think of some changes. But they're not relevant to the
discussion here.

-john

Todd Rinaldo

unread,
Nov 11, 2011, 10:52:53 AM11/11/11
to John M. Gamble, David Nicol, Module Authors

On Nov 11, 2011, at 9:20 AM, John M. Gamble wrote:

> I think the barrier to making local forks is already very low and there is no reason to switch the whole thing to Git.

I usually use gitpan when I want to fork a module and can't find it's source history. https://github.com/gitpan

Olaf Alders

unread,
Nov 11, 2011, 11:53:15 AM11/11/11
to Todd Rinaldo, John M. Gamble, David Nicol, Module Authors
Gitpan is no longer actively maintained AFAIK. See the issues list for how to revive it.

Olaf

yan...@babyl.dyndns.org

unread,
Nov 11, 2011, 1:45:02 PM11/11/11
to Olaf Alders, Todd Rinaldo, John M. Gamble, David Nicol, Module Authors
On Fri, Nov 11, 2011 at 11:53:15AM -0500, Olaf Alders wrote:
> Gitpan is no longer actively maintained AFAIK. See the issues list for how to revive it.

And that's my cue to point out that while Gitpan isn't updated,
you can still use Git::CPAN::Patch, the module Gitpan is using under
the hood.

# create git repo seeded with the module's CPAN latest version
$ git cpan-init Foo::Bar

# create git repo seeded with the full BackPAN history of the
# module
$ git backpan-init Foo::Bar

And, yes, one of the requested new feature for G:C:P is to be able to grok
a distribution's META.yml and clone its clone repo if it already exist.
It's something I'll work on as soon as I have some tuits. :-)

Joy,
`/anick

Neil Bowers

unread,
Nov 10, 2011, 6:27:04 PM11/10/11
to Yanick Champoux, module-...@perl.org
>> To make life easier for the perl modules cabal, how about a voluntary
>> pledge
>
> Nice idea. I like.

Good!

> 1. Maintainer has retired / is not interested anymore / has been abducted by aliens / etc.
>
> [...] I was thinking of something quite similar where distributions would be tagged as orphaned after one year of inactivity, where activity is defined as (a) release a new version or (b) push a "yeah, yeah, I'm still here and interested" button somewhere. To be successful, such a scheme should be careful to let maintainers know (in a non-spammy way) in advance that their time is running out, to prevent nasty surprises, and it should be easy and pain-free, even for the maintainers with lots of distributions.

Interesting thought. How about:

- if a distribution author appears to be inactive, then the author would receive an email to their registered
CPAN email address saying "this distro appears to be inactive, just reply to this email to let me know otherwise".
- An inactive module would be one with no release in the last N months, and some minimum number of
RT issues.

Replying to the email would essentially be saying to PAUSE, "Still interested, don't give it away".

The lack of a release isn't a sufficient criterion for inactive: there are plenty of solid modules which don't need
a release, because there's nothing to be done.

I think this would still have to be a mechanism that an author has to sign up to, rather than it automatically
being applied.

> 2. Maintainer wants help
>
> The other case is when a maintainer is still around, but either doesn't want to maintain a distribution anymore, or wouldn't mind a wee bit of help. [...]
>
> Maybe the solution to (1) and (2) lies with a site that would be the flip side of prepan.org (orPhAN.org ? :-) ), where modules up for adoption are listed? But Neil brought the crucial point (I think), that no matter what, the passing of maintainership should never be done totally automatically, but should always at least get the blessing of the gardians of mod...@perl.org or the ex-maintainer herself. Just, y'know, as human sanity check.

There could be two ways you could tag a module:

(a) up for adoption
(b) open to adoption requests

For case (a), you're essentially saying that you don't plan to do any updates, and if anyone's interested in taking it over,
then if mod...@perl.org are happy with the suitors intentions (um, mixing my metaphors here), then they can hand
over the keys.

But at least one of my distros I'd tag with (b): I hope to do more releases, but if someone really wants to take it
forward, and convince me that they're serious, I'd hand it over.

All the modules tagged (a) could be listed, and searchable on metacpan.org, for example. So if someone's looking
for a side perl project, they could search this list for a module that appeals to them.

A bunch of related ideas here, but we don't want to make things too complex.

Neil


Olaf Alders

unread,
Nov 11, 2011, 4:07:46 PM11/11/11
to Neil Bowers, Yanick Champoux, module-...@perl.org

On 2011-11-10, at 6:27 PM, Neil Bowers wrote:
>> 2. Maintainer wants help
>>
>> The other case is when a maintainer is still around, but either doesn't want to maintain a distribution anymore, or wouldn't mind a wee bit of help. [...]
>>
>> Maybe the solution to (1) and (2) lies with a site that would be the flip side of prepan.org (orPhAN.org ? :-) ), where modules up for adoption are listed? But Neil brought the crucial point (I think), that no matter what, the passing of maintainership should never be done totally automatically, but should always at least get the blessing of the gardians of mod...@perl.org or the ex-maintainer herself. Just, y'know, as human sanity check.
>
> There could be two ways you could tag a module:
>
> (a) up for adoption
> (b) open to adoption requests

(c) open to co-parenting?

yan...@babyl.dyndns.org

unread,
Nov 11, 2011, 5:43:23 PM11/11/11
to Neil Bowers, Yanick Champoux, module-...@perl.org
On Thu, Nov 10, 2011 at 11:27:04PM +0000, Neil Bowers wrote:
> Interesting thought. How about:
>
> - if a distribution author appears to be inactive, then the author would receive an email to their registered
> CPAN email address saying "this distro appears to be inactive, just reply to this email to let me know otherwise".

That's the tricky part where the the system has not to be too spammy.
For peeps with one or two dists, it's not an issue. For the CPAN titans
who are owning hundreds of distributions, we... probably don't want to
send an email for every module. We should have at most an aggregated
reminder every X weeks, and allow for the author to see/select her
distros in a single, easy way.

> The lack of a release isn't a sufficient criterion for inactive: there are plenty of solid modules which don't need
> a release, because there's nothing to be done.

Exactly.

> I think this would still have to be a mechanism that an author has to sign up to, rather than it automatically
> being applied.

Considering the nature of CPAN, I tend to agree. Trying to force
it everyone's throat would be the best way to quickly and utterly doom
the project. And probably ensure to wake up one morning with a camel's
head in our bed. :-)


> There could be two ways you could tag a module:
>
> (a) up for adoption
> (b) open to adoption requests

and, as Olaf mentioned, (c) open to co-parenting / wouldn't mind
some help


Joy,
`/anick


--

Bill Ward

unread,
Nov 11, 2011, 4:30:38 PM11/11/11
to yan...@babyl.dyndns.org, Neil Bowers, module-...@perl.org
On Fri, Nov 11, 2011 at 2:43 PM, <yan...@babyl.dyndns.org> wrote:
On Thu, Nov 10, 2011 at 11:27:04PM +0000, Neil Bowers wrote:
> Interesting thought. How about:
>
>       - if a distribution author appears to be inactive, then the author would receive an email to their registered
>         CPAN email address saying "this distro appears to be inactive, just reply to this email to let me know otherwise".

That's the tricky part where the the system has not to be too spammy.
For peeps with one or two dists, it's not an issue. For the CPAN titans
who are owning hundreds of distributions, we... probably don't want to
send an email for every module.  We should have at most an aggregated
reminder every X weeks, and allow for the author to see/select her
distros in a single, easy way.


How about just do it by author - if any of the author's distros are idle for 6 months, send them an email?

Aristotle Pagaltzis

unread,
Nov 11, 2011, 6:29:25 PM11/11/11
to module-...@perl.org
* yan...@babyl.dyndns.org <yan...@babyl.dyndns.org> [2011-11-11 22:30]:
> On Thu, Nov 10, 2011 at 11:27:04PM +0000, Neil Bowers wrote:
> > I think this would still have to be a mechanism that an author has
> > to sign up to, rather than it automatically being applied.
>
> Considering the nature of CPAN, I tend to agree. Trying to force it
> everyone's throat would be the best way to quickly and utterly doom
> the project. And probably ensure to wake up one morning with a camel's
> head in our bed. :-)

Or a severed one under your bed sheets…

Yanick Champoux

unread,
Nov 12, 2011, 10:25:51 PM11/12/11
to module-...@perl.org
On 11-11-11 06:29 PM, Aristotle Pagaltzis wrote:
>> Considering the nature of CPAN, I tend to agree. Trying to force it
>> > everyone's throat would be the best way to quickly and utterly doom
>> > the project. And probably ensure to wake up one morning with a camel's
>> > head in our bed.:-)
> Or a severed one under your bed sheets…

Yeah, that's pretty much what I had in mind. Although, on second
thought, waking up to the sight of a live camel munching on one's
bed-sheets is probably scarier, all things considered.

Joy,
`/anick

David Cantrell

unread,
Nov 14, 2011, 6:33:15 AM11/14/11
to module-...@perl.org
On Fri, Nov 11, 2011 at 01:30:38PM -0800, Bill Ward wrote:

> How about just do it by author - if any of the author's distros are idle
> for 6 months, send them an email?

No. It's pointless. We already have a system that works, so let's not
try to fix it.

--
David Cantrell | Cake Smuggler Extraordinaire

There are many different types of sausages. The best are
from the north of England. The wurst are from Germany.
-- seen in alt.2eggs...
Reply all
Reply to author
Forward
0 new messages