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
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 modules@perl.org. I'll be emailing the following to
modules@perl.org:

    I hereby give modules@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?

0
neil
11/8/2011 4:22:02 PM
perl.module-authors 1604 articles. 0 followers. Follow

34 Replies
1037 Views

Similar Articles

[PageSpeed] 35
Get it on Google Play
Get it on Apple App Store

--bcaec52995896ee84704b15e54ed
Content-Type: text/plain; charset=ISO-8859-1

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.

On Wed, Nov 9, 2011 at 1:22 AM, Neil Bowers <neil@bowers.com> 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.
>
> 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 modules@perl.org. I'll be emailing the following to
> modules@perl.org:
>
>    I hereby give modules@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?
>
>

--bcaec52995896ee84704b15e54ed
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

I am against the &#39;if I die&#39; part. As we are all communication over =
the net, it is very difficult to know why a person have stopped responding.=
=A0<div>And it make the statement a bit scary.</div><div><br></div><div>Shm=
uel.<br>
<br><div class=3D"gmail_quote">On Wed, Nov 9, 2011 at 1:22 AM, Neil Bowers =
<span dir=3D"ltr">&lt;<a href=3D"mailto:neil@bowers.com">neil@bowers.com</a=
>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 =
0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
One of the problems I see with CPAN is that there are many modules<br>
which have been left unattended. Many of these have outstanding bugs,<br>
and a good number have patches and forked versions, some of which you can<b=
r>
find on RT. You&#39;ll also find people offering to take over the maintaine=
rship<br>
of modules. While reviewing modules I&#39;ve identified a lot of fixes, and=
<br>
documentation improvements, but it can take a lot of effort to get them out=
..<br>
<br>
If the author or current maintainer of a module is unresponsive, there&#39;=
s<br>
a well-defined, but lengthy, process to request co-maintainership.<br>
There are good reasons for this -- I&#39;ll assume you&#39;ve read them.<br=
>
But in reality, plenty of authors lose interest<br>
<br>
To make life easier for the perl modules cabal, how about a voluntary<br>
pledge[*], which module authors can take publically, and in particular<br>
can take to <a href=3D"mailto:modules@perl.org">modules@perl.org</a>. I&#39=
;ll be emailing the following to<br>
<a href=3D"mailto:modules@perl.org">modules@perl.org</a>:<br>
<br>
 =A0 =A0I hereby give <a href=3D"mailto:modules@perl.org">modules@perl.org<=
/a> permission to grant co-maintainership<br>
 =A0 =A0to any of my modules, if the following conditions are met:<br>
<br>
 =A0 =A0(1) I haven&#39;t released the module for a year or more<br>
 =A0 =A0(2) There are outstanding issues on RT which need addressing<br>
 =A0 =A0(3) Email to my CPAN email address hasn&#39;t been answered after a=
 month<br>
 =A0 =A0(4) The requester wants to make worthwhile changes that will benefi=
t CPAN<br>
<br>
 =A0 =A0Should I die, then the time-limits in (1) and (3) do not apply.<br>
<br>
This means it will be archived, and easily accessed. I&#39;ll put this in t=
he<br>
README for my modules.<br>
<br>
If others, and particularly the modules cabal, think this is a good idea,<b=
r>
maybe we could have a canonical place this this, which can be easily<br>
referred to. Perhaps PAUSE could let me record it, so there&#39;s one place=
<br>
the modules cabal can check? Or you could put it in module metadata?<br>
<br>
So, what do y&#39;all think?<br>
<br>
Neil,<br>
in the light of recent discussions, donning flame-retardent long-johns.<br>
<br>
[*] I tried to come up with a catchy name for this, but failed. Ideas?<br>
<br>
</blockquote></div><br></div>

--bcaec52995896ee84704b15e54ed--
0
shmuelfomberg
11/10/2011 9:50:08 AM
-------- Original-Nachricht --------
> Datum: Tue, 8 Nov 2011 16:22:02 +0000
> Von: Neil Bowers <neil@bowers.com>
> An: module-authors@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
0
burakgursoy
11/10/2011 10:17:37 AM
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
0
brontolinux
11/10/2011 10:17:52 AM
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]
>         
>            I hereby give modules@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?



0
raph
11/10/2011 10:22:00 AM
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)? ;)
0
davidp
11/10/2011 10:27:56 AM
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

0
b
11/10/2011 10:29:09 AM
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.=20=

> 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

0
neil
11/10/2011 10:36:44 AM
--Apple-Mail=_E0DC6942-D7C9-4281-A2C8-E10924CFF96F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=iso-8859-1

> Being on the patch submitting side of this, I'll put in my 2 pence.
>=20
> 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=3Dpause_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.


--Apple-Mail=_E0DC6942-D7C9-4281-A2C8-E10924CFF96F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=iso-8859-1

<html><head></head><body style=3D"word-wrap: break-word; =
-webkit-nbsp-mode: space; -webkit-line-break: after-white-space; =
"><div><blockquote type=3D"cite"><div>Being on the patch submitting side =
of this, I'll put in my 2 pence.<br><br>For the last 2 years, I've been =
bugging one CPAN author to apply my patch<br>that fixes a bug in RT. =
&nbsp;He says, "I've moved to GitHub. &nbsp;Fork my project and<br>issue =
a pull request". =
&nbsp;[...]<br></div></blockquote><div><br></div><div>I've got a few of =
those going on.</div><div><br></div><div>But in reviewing a bunch of =
modules recently, I've hit more of the following case:</div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>- no =
releases in a long time</div><div><span class=3D"Apple-tab-span" =
style=3D"white-space:pre">	</span>- I submit things to RT with no =
response (usually other tickets already there)</div><div><span =
class=3D"Apple-tab-span" style=3D"white-space:pre">	</span>- I email =
the author, and get no response</div><div><br></div><div>I've come up =
with bugs for a number of modules, some of which I'm now going =
through</div><div>the adoption process on, but some I'm figuring it's =
just not worth it, which is a shame.</div><br><blockquote =
type=3D"cite"><div>Technology doesn't make people&nbsp;interested in old =
projects when there's new shiny to work =
on.<br></div></blockquote><div><br></div>Spot =
on.</div><div><br></div><div>If someone comes along and thinks "hey, =
this would be useful, and I can improve it",</div><div>we should make it =
easier for the baton to be passed on, as it will improve the overall =
quality</div><div>of CPAN.</div><div><br></div><div>All the while still =
respecting the original author [1]</div><div><br><blockquote =
type=3D"cite"><div>Or is it me? &nbsp;What's the matter? &nbsp;Do I =
stink?<br></div></blockquote><div><br></div><div>Well, to borrow your =
phrase, given the demographic, you probably do =
;-)</div><div><br></div><div>This pledge is one of the ideas which came =
from reviewing a bunch of modules,</div><div>which I'm presenting at the =
London Perl Workshop. You =
going?</div><div><br></div><div>Neil</div><div><br></div><div><br></div></=
div>[1] I like the statement on respecting the original author in the =
PAUSE rules:<div><br></div><div><a =
href=3D"http://pause.perl.org/pause/query?ACTION=3Dpause_04about">http://p=
ause.perl.org/pause/query?ACTION=3Dpause_04about</a><div><br></div><div><s=
pan class=3D"Apple-style-span" style=3D"-webkit-border-horizontal-spacing:=
 2px; -webkit-border-vertical-spacing: 2px; font-family: Times; ">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.</span></div><div><span =
class=3D"Apple-style-span" style=3D"-webkit-border-horizontal-spacing: =
2px; -webkit-border-vertical-spacing: 2px; font-family: Times; =
"><br></span></div></div></body></html>=

--Apple-Mail=_E0DC6942-D7C9-4281-A2C8-E10924CFF96F--
0
neil
11/10/2011 11:11:23 AM
On Tue, Nov 8, 2011 at 5:22 PM, Neil Bowers <neil@bowers.com> 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 maintainers=
hip
> 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 o=
ut.
>
> 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 modules@perl.org. I'll be emailing the following to
> modules@perl.org:
>
> =C2=A0 =C2=A0I hereby give modules@perl.org permission to grant co-mainta=
inership
> =C2=A0 =C2=A0to any of my modules, if the following conditions are met:
>
> =C2=A0 =C2=A0(1) I haven't released the module for a year or more
> =C2=A0 =C2=A0(2) There are outstanding issues on RT which need addressing
> =C2=A0 =C2=A0(3) Email to my CPAN email address hasn't been answered afte=
r a month
> =C2=A0 =C2=A0(4) The requester wants to make worthwhile changes that will=
 benefit CPAN
>
> =C2=A0 =C2=A0Should I die, then the time-limits in (1) and (3) do not app=
ly.
>
> 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?

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
0
fawaka
11/10/2011 12:00:14 PM
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

0
b
11/10/2011 12:09:37 PM
--Sig_/H8cVPcd4Q89AXialk1VeCHw
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

> 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

--Sig_/H8cVPcd4Q89AXialk1VeCHw
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)

iEYEARECAAYFAk67xGkACgkQFtlTdOX00HpSVwCeNjeaix3iTQ1dtYQWWVT9np99
gdUAn3ev9AnBLXt/0+hcclvyN+tJwkQK
=0tq6
-----END PGP SIGNATURE-----

--Sig_/H8cVPcd4Q89AXialk1VeCHw--
0
daxim
11/10/2011 12:32:29 PM
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
0
shawnhcorey
11/10/2011 1:33:16 PM
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

0
neil
11/10/2011 1:34:40 PM
On Thu, Nov 10, 2011 at 1:32 PM, Lars D=C9=AA=E1=B4=87=E1=B4=84=E1=B4=8B=E1=
=B4=8F=E1=B4=A1 =E8=BF=AA=E6=8B=89=E6=96=AF <daxim@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
0
fawaka
11/10/2011 2:15:23 PM
On Tue, Nov 08, 2011 at 04:22:02PM +0000, Neil Bowers wrote:

>     I hereby give modules@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
0
david
11/10/2011 2:58:23 PM
--0016368e1e959bfbbb04b163a5be
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

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.

On Thu, Nov 10, 2011 at 6:58 AM, David Cantrell <david@cantrell.org.uk>wrot=
e:

> On Tue, Nov 08, 2011 at 04:22:02PM +0000, Neil Bowers wrote:
>
> >     I hereby give modules@perl.org permission to grant co-maintainershi=
p
> >     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 mon=
th
> >     (4) The requester wants to make worthwhile changes that will benefi=
t
> 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
>



--=20
Check out my LEGO blog at http://www.brickpile.com
Follow/friend me: facebook.com/billward =95 flickr.com/photos/billward =95
twitter.com/williamward

--0016368e1e959bfbbb04b163a5be
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

I think the &quot;Should I die&quot; (though I think &quot;in the event of =
my death&quot; would be better) can only really work if a family member rep=
lies to the email saying that the maintainer has passed away, which isn&#39=
;t too likely but could happen. Since those time limits would expire eventu=
ally anyway, it&#39;s probably not necessary except that it speeds up the p=
rocess---*if* you get confirmation of death.<br>

<br><div class=3D"gmail_quote">On Thu, Nov 10, 2011 at 6:58 AM, David Cantr=
ell <span dir=3D"ltr">&lt;<a href=3D"mailto:david@cantrell.org.uk">david@ca=
ntrell.org.uk</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class=3D"im">On Tue, Nov 08, 2011 at 04:22:02PM +0000, Neil Bowers wro=
te:<br>
<br>
&gt; =A0 =A0 I hereby give <a href=3D"mailto:modules@perl.org">modules@perl=
..org</a> permission to grant co-maintainership<br>
&gt; =A0 =A0 to any of my modules, if the following conditions are met:<br>
&gt;<br>
&gt; =A0 =A0 (1) I haven&#39;t released the module for a year or more<br>
&gt; =A0 =A0 (2) There are outstanding issues on RT which need addressing<b=
r>
&gt; =A0 =A0 (3) Email to my CPAN email address hasn&#39;t been answered af=
ter a month<br>
&gt; =A0 =A0 (4) The requester wants to make worthwhile changes that will b=
enefit CPAN<br>
&gt;<br>
&gt; =A0 =A0 Should I die, then the time-limits in (1) and (3) do not apply=
..<br>
&gt;<br>
</div><div class=3D"im">&gt; So, what do y&#39;all think?<br>
<br>
</div>I think that this isn&#39;t really different from what happens now an=
yway.<br>
<span class=3D"HOEnZb"><font color=3D"#888888"><br>
--<br>
David Cantrell | Reality Engineer, Ministry of Information<br>
</font></span></blockquote></div><br><br clear=3D"all"><br>-- <br>Check out=
 my LEGO blog at <a href=3D"http://www.brickpile.com/" target=3D"_blank">ht=
tp://www.brickpile.com</a><br>Follow/friend me: <a href=3D"http://facebook.=
com/billward" target=3D"_blank">facebook.com/billward</a> =95 <a href=3D"ht=
tp://flickr.com/photos/billward/" target=3D"_blank">flickr.com/photos/billw=
ard</a> =95 <a href=3D"http://twitter.com/williamward" target=3D"_blank">tw=
itter.com/williamward</a><br>

<br>

--0016368e1e959bfbbb04b163a5be--
0
bill
11/10/2011 4:10:04 PM
On Thu, Nov 10, 2011 at 11:10 AM, Bill Ward <bill@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.
0
michael
11/10/2011 4:33:16 PM
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 modules@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
0
yanick
11/10/2011 5:46:12 PM
>>    I hereby give modules@perl.org permission to grant =
co-maintainership
>>    to any of my modules, if the following conditions are met:
>>=20
>>    (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 [...]
>=20
> 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

0
neil
11/10/2011 10:41:23 PM
>> To make life easier for the perl modules cabal, how about a voluntary
>> pledge
>=20
> 	Nice idea. I like.

Good!

> 1. Maintainer has retired / is not interested anymore / has been =
abducted by aliens / etc.
>=20
> [...] 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.=20

> 2. Maintainer wants help
>=20
> 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.  [...]
>=20
> 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 modules@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 modules@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


0
neil
11/10/2011 11:27:04 PM
On Thu, Nov 10, 2011 at 10:41:23PM +0000, Neil Bowers wrote:
> >>    I hereby give modules@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.
0
david
11/11/2011 12:48:18 AM
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.=20
>> And it make the statement a bit scary.
>=20
> 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.
>=20
> 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
olaf@wundersolutions.com

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

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

0
olaf
11/11/2011 1:48:23 AM
--0016364993339faa4d04b16d30fe
Content-Type: text/plain; charset=UTF-8

> 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 modules@perl.org. I'll be emailing the following to
>> modules@perl.org:
>>
>
No.
The license chaos is enough as it now is.


>
>>    I hereby give modules@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

--0016364993339faa4d04b16d30fe
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<br><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div cl=
ass=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex">

To make life easier for the perl modules cabal, how about a voluntary<br>
pledge[*], which module authors can take publically, and in particular<br>
can take to <a href=3D"mailto:modules@perl.org" target=3D"_blank">modules@p=
erl.org</a>. I&#39;ll be emailing the following to<br>
<a href=3D"mailto:modules@perl.org" target=3D"_blank">modules@perl.org</a>:=
<br></blockquote></div></div></blockquote><div><br>No. <br>The license chao=
s is enough as it now is.<br>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 20=
4); padding-left: 1ex;">
<div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"=
margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddi=
ng-left: 1ex;">
<br>
 =C2=A0 =C2=A0I hereby give <a href=3D"mailto:modules@perl.org" target=3D"_=
blank">modules@perl.org</a> permission to grant co-maintainership<br>
 =C2=A0 =C2=A0to any of my modules, if the following conditions are met:<br=
>
<br>
 =C2=A0 =C2=A0(1) I haven&#39;t released the module for a year or more<br><=
/blockquote></div></div></blockquote><div><br>Complete modules don&#39;t ge=
t re-released, so this condition cannot be sufficient on its own ... oh, th=
at doesn&#39;t say &quot;any of the...&quot; does it. Sorry.<br>
<br>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin: 0pt 0pt =
0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><=
div><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"m=
argin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); paddin=
g-left: 1ex;">

 =C2=A0 =C2=A0(2) There are outstanding issues on RT which need addressing<=
br>
 =C2=A0 =C2=A0(3) Email to my CPAN email address hasn&#39;t been answered a=
fter a month<br>
 =C2=A0 =C2=A0(4) The requester wants to make worthwhile changes that will =
benefit CPAN<br>
<br>
So, what do y&#39;all think?<br></blockquote></div></div></blockquote><div>=
<br>I think this is not necessary at all.=C2=A0 I think you have pretty muc=
h described the current standards for granting takeover. I think the barrie=
r to making local forks is already very low and there is no reason to switc=
h the whole thing to Git.<br>
<br>I think CPAN is fine as it is.<br></div></div><br>-- <br>&quot;One only=
 understands the things that one tames&quot; -- the fox<br>

--0016364993339faa4d04b16d30fe--
0
davidnicol
11/11/2011 3:33:52 AM
On Nov 10, 2011, at 4:41 PM, Neil Bowers wrote:

>>>   I hereby give modules@perl.org permission to grant =
co-maintainership
>>>   to any of my modules, if the following conditions are met:
>>>=20
>>>   (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 [...]
>>=20
>> I think that this isn't really different from what happens now =
anyway.
>=20
> 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 modules@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.=20
=20
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 modules@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.=20
Todd=
0
toddr
11/11/2011 2:38:35 PM
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

0
jgamble
11/11/2011 3:20:34 PM
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=
0
toddr
11/11/2011 3:52:53 PM
On 2011-11-11, at 10:52, Todd Rinaldo <toddr@cpanel.net> wrote:

>=20
> On Nov 11, 2011, at 9:20 AM, John M. Gamble wrote:
>=20
>> I think the barrier to making local forks is already very low and there i=
s no reason to switch the whole thing to Git.
>=20
> I usually use gitpan when I want to fork a module and can't find it's sour=
ce history.  https://github.com/gitpan

Gitpan is no longer actively maintained AFAIK. See the issues list for how t=
o revive it.=20

Olaf=
0
olaf
11/11/2011 4:53:15 PM
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
0
yanick
11/11/2011 6:45:02 PM
On 2011-11-10, at 6:27 PM, Neil Bowers wrote:
>> 2. Maintainer wants help
>>=20
>> 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.  [...]
>>=20
>> 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 modules@perl.org or the ex-maintainer herself. Just, =
y'know, as human sanity check.
>=20
> There could be two ways you could tag a module:
>=20
> 	(a) up for adoption
> 	(b) open to adoption requests

(c) open to co-parenting?

Olaf
--
Olaf Alders
olaf@wundersolutions.com

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

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

0
olaf
11/11/2011 9:07:46 PM
--0016368e1e95f1ae4504b17c3d8a
Content-Type: text/plain; charset=ISO-8859-1

On Fri, Nov 11, 2011 at 2:43 PM, <yanick@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?

--0016368e1e95f1ae4504b17c3d8a
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On Fri, Nov 11, 2011 at 2:43 PM,  <span dir=3D"ltr">&lt;<a href=3D"mailto:y=
anick@babyl.dyndns.org">yanick@babyl.dyndns.org</a>&gt;</span> wrote:<br><d=
iv class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:=
0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class=3D"im">On Thu, Nov 10, 2011 at 11:27:04PM +0000, Neil Bowers wro=
te:<br>
&gt; Interesting thought. How about:<br>
&gt;<br>
&gt; =A0 =A0 =A0 - if a distribution author appears to be inactive, then th=
e author would receive an email to their registered<br>
&gt; =A0 =A0 =A0 =A0 CPAN email address saying &quot;this distro appears to=
 be inactive, just reply to this email to let me know otherwise&quot;.<br>
<br>
</div>That&#39;s the tricky part where the the system has not to be too spa=
mmy.<br>
For peeps with one or two dists, it&#39;s not an issue. For the CPAN titans=
<br>
who are owning hundreds of distributions, we... probably don&#39;t want to<=
br>
send an email for every module. =A0We should have at most an aggregated<br>
reminder every X weeks, and allow for the author to see/select her<br>
distros in a single, easy way.<br><br></blockquote><div><br>How about just =
do it by author - if any of the author&#39;s distros are idle for 6 months,=
 send them an email? <br></div></div>

--0016368e1e95f1ae4504b17c3d8a--
0
bill
11/11/2011 9:30:38 PM
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


-- 
0
yanick
11/11/2011 10:43:23 PM
* yanick@babyl.dyndns.org <yanick@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…
0
pagaltzis
11/11/2011 11:29:25 PM
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

0
yanick
11/13/2011 3:25:51 AM
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...
0
david
11/14/2011 11:33:15 AM
Reply:

Similar Artilces:

modules, modules
This site appears to be the most comprehensive list of free custom modules: www.dnnfaq.com Any other sites? I do like how Rainbow gives you a bucket of them - saves a lot of time over having to snoop around and find some of the DNN ones. Is there also a way to list modules as "certified"? Also - is there a decent repository of skins? I have recently installed version 2.0. Sure wish there were more modules ready for it! That would make it much easier to evaluate the program and give recommendations to my boss. The reason there aren't more 2.0 modules yet is becasue it h...

MX module authors
The next Moose will start warning on various deprecated features, most of which have been deprecated for quite some time without warning. You can take a look at the current list of failures & warnings by checking out http://urth.org/~autarch/mydeps-error.log You should be able to simply search for your PAUSE id to see the status of your modules. It would be great if you could get a warnings-clean release out before the next Moose release, which I'm hoping to do some time in the next week or so. -dave /*=========================================================...

Module in Module
Hi, Is there a way to place a module inside another module (e.g. A feedback module inside a Text/HTML module) ? Cheers Tassos There is a way to inject controls into a module dynamically based on some criteria like a querystring parameter - is that what you are wanting to do?Dylan Barberread my stupid blog http://codemypantsoff.com There's a commercial module "wrapper" on Snowcovered that is designed to hold other modules.  So it is possible.I don't know if you could put a module holding a module inside a module containing a module, but I wouldn't try.  The entire space-time...

Attempt to contact module author Shlomo Yona (SuffixTree module on CPAN)
The module author Shlomo Yona for the Perl Module SuffixTree lists an email address that is no longer valid. An email has been sent to this author's @cpan.org email address as well (I'm hopeful that there will be a response, but as of now haven't). There are bug reports in the RT that include patches ranging from 2 years old to 8 years old. The module was first uploaded in January of 2003, with two subsequent revisions also in January 2003. No activity since then. This message is an attempt to contact Shlomo Yona. If you know how to reach him please let me know. If ...

Module author not responding
--f46d0442810a09763b05014ebb15 Content-Type: text/plain; charset=UTF-8 Hello, What's the process if a module author does not respond to bug reports or change/enhancement requests? Regards, Ashish -- M: +91-8800199037 --f46d0442810a09763b05014ebb15 Content-Type: text/html; charset=UTF-8 <div dir="ltr">Hello,<div><br></div><div>What&#39;s the process if a module author does not respond to bug reports or change/enhancement requests?</div><div><br></div><div>Regards,</div><div>Ashish&l...

custom authorization module
Hi all, I have been able to write custom membership and role providers that authenticate a user against my database and then also retrieve roles from my database. Now what I need to do is the following:-1. Custom authorization module:   a. Check permission for user/role at folder level.   b. Check permission for user/role at file (.aspx) level.   c. Check write/modify for user/role permission at file (.aspx) level.2. Some ideas are:-   a. Have my .aspx page implement a certain interface (ICustomPage) whereby everytime a postbac...

Module/Class Authoritys
Quick question for the group. Can there be more than one authority? module Foo-0.0.1-cpan:JRANDOM-http://www.foo.org-mailto:jrandom@foo.org S11 would seem to indicate no (it states that names are made up of 3 parts), but I guess I am wondering if one of those parts can have multiple sub-parts in it? Thanks, - Stevan At 12:35 AM -0400 8/11/06, Stevan Little wrote: >Quick question for the group. > >Can there be more than one authority? > >module Foo-0.0.1-cpan:JRANDOM-http://www.foo.org-mailto:jrandom@foo.org > >S11 would seem to indicate no (it sta...

Authorizing loaded modules
 I have expanded on the help from http://forums.asp.net/t/1136679.aspx and now want continue with this a bit further to include authorization. Using the following as an example:public bool LoadSection(string segment)        {            bool sectionLoaded = false;            _objMenuGroup = new MenuGroup(segment);            if (_objMenuGroup == null || _objMenuGroup.MenuGroupID <= ...

sub modules, loading custom modules into a parent module
GreetingsI am creating a support system module which will require the ability to add sub modules. For example, there is an admininstrators section in which suport requests are administered, anwsered, solved etc.There is to be another function in the admin section of the support module in which admins can upload a new support form template module, ie, say an admin wants to set up a form for users to lodge a request for new hardware, the form will display all required fields, graphics, validation etc for that request. Another support form template might be to have a new user set up on the acti...

Modules Containing Modules
I have no idea if this is possible or not, but I'm keeping my fingers crossed. Basically, what I need is a module container that can hold other modules. The reason is because on some views within my portal site, I need to have multiple regions (i.e. links, static text/html). I'm sure I can create different modules for specific scenarios, but this happens A LOT, so I'm hoping there's already something doing it. I have yet to dig into building my first module, so it may not even be a big deal. Has anyone attempted this before? If so, are there any public tools already published that I'...

A Module inside a Module ??
Hi DNN Community, I've developed a DNN module (let's call it module X) which is included in my DNN website as a private assembly. However, I'l like to add a scrolling marque usercontrol to my module X. As a start, I purchased a scrolling marquee module from snowcovered which works great as a stand alone module. However, I'd like to modify this module so it fits into my module X. Can anyone explain to me how to do this, and if there is any source code available where I could see how this is done. Thanks in advance, Brad How about putting a placeholder control in your module X then...

How to load modules into modules
Title says it all. I want to load (custom) modules within a custom module. But I havent the slightest idea how to do that. Any suggestions? thx Like this: Dim _MyControl as _MyControl _MyControl = CType(Me.LoadControl("MyControl .ascx"), MyControl) ParentControl.Controls.Add(_MyControl) Leigh PointerUser Group Champion » Evangelising DotNetNuke Everywhere « The method LoadControl works, if your loaded custom module doesn't need do raise PostbackEvents :-( If you need that... Than this way is impossible for you. I will post how to do it right in...

Load module into module...
Is it possible to load a module into another module? I'm thinking in particular of the Internal Links Module available @ www.cortinc.com I use this module a lot and with a few enhancements it has served me well, however it has one flaw...each link only allows html data...because it is just a holder that loads the html from the db. It would be a great enhancement to be able to add other modules to these links i.e. announcements, news, pictures etc but they would in effect have to be loaded into another module. Any thoughts would be appreciated on how I should approach this or whether it...

Module within a Module
Anyone experiemented with IBS to create a module that could contain other IBS modules?Robbie Freeland Web Team Leader www.chesterfield.gov yeah - with limited sucess as things started to go screwey after a while with the containers - it is something I still want to get working - but I dont seem to have the time to do so at the momentVarious IBS Addons available at http://www.snowcovered.comLead Developer [vb & c#] - MCAD I have been able to do it, just displaying information in datagrids, but I had to pass variables in the URL to keep the nested module active and visible as the page re...

Web resources about - The module authors pledge - perl.module-authors

List of atheist authors - Wikipedia, the free encyclopedia
Forrest J Ackerman (1916–2008): American writer, historian, editor, collector of science fiction books and movie memorabilia and a science fiction ...

Microsoft let a bunch of top sci-fi authors into its research labs — and the results are amazing
... holographic goggles. Other projects include machine learning technology " Project Oxford ," artificial intelligence , and more. "The authors ...

Texan of the Year finalist: Author Sarah Hepola
Her memoir “Blackout: Remembering the Things I Drank to Forget” is part of the national discussion on women and alcohol.

'Game Of Thrones' Author George R.R. Martin: 'Winds Of Winter' Won't Be Ready Before Season 6
"Game of Thrones" author George R.R. Martin announced that "The Winds of Winter" won't be published before the season 6 of the hit HBO fantasy ...

Will The 'Always Hungry' Diet Revolutionize Weight Loss? A Q&A With The Author, Dr. David Ludwig
Dr. David Ludwig's new diet book, Always Hungry?, turns traditional diet advice on its head with its premise that overeating doesn’t make you ...

'Game of Thrones' Author George R.R. Martin Says Next Book Not Finished Yet
"Game of Thrones" fans won't like what author George R.R. Martin revealed Saturday the sixth book in the fantasy series, "The Winds of Winter," ...


8 Best Selling Indie Authors Share Their New Year's Resolutions
No more snacking between writing chapters? Working harder on promotion? Or just trying to relax more between penning bestsellers?

‘Game of Thrones’ Author George R.R. Martin Blames Fandom For ‘The Winds of Winter’ Delay
Brace yourselves, Game Of Thrones fans, because author George R.R. Martin is taking his sweet time with releasing the sixth book in the series, ...

Author Of Letter On Texas F1 Race Funding Said It Wasn't Meant To Be A Binding Contract
A 2010 letter from former Texas Comptroller of Public Accounts Susan Combs is making the rounds again, giving hope that the state would contribute ...

Resources last updated: 1/8/2016 1:26:14 PM