The module authors pledge

[Neil Bowers]

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]

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

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

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]

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]

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]

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]

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]

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ɪᴇᴄᴋᴏᴡ 迪拉斯]

> 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

[Shawn H Corey]

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]

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]

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]

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/billward • flickr.com/photos/billward • twitter.com/williamward

[Yanick Champoux]

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]

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]

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]

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]

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

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]

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]

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]

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]

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]

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]

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]

Gitpan is no longer actively maintained AFAIK. See the issues list for how to revive it.

Olaf

[yan...@babyl.dyndns.org]

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]

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

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]

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]

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]

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

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]

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