Starting a module's history from gitpan
Buddy Burden
So, I found a bug in a CPAN module that hadn't been updated in some
time. After I submitted a bug in RT, I checked the author's other
modules and his RT tickets: no activity in years. So I sent the
author an email, and said, hey, if you don't want to mess with this
module any more, I'd be happy to take it over for you. And, voila,
I'm now the proud(?) maintainer of Data::Random.
So I need to create a repo for the code, and it would be nice to start
with the previous versions, right? Happily, there is gitpan, so I can
pretty easily access all the CPAN versions of the code at least. Now,
I've read Schwern's blog[1] on how to merge gitpan history into an
existing repo, so I could essentially create a blank repo, do the
merge as he describes, and go from there. But it seems to me that's
unnecessarily complex, since I'm starting from scratch. What I'm
wondering is, couldn't I just fork the gitpan repo for Data::Random[2]
and have that become my repo? Obviously I would never plan on merging
it back, but that shouldn't matter, I don't think.
Does anyone see any downsides to this plan, or have a better suggestion? TIA!
-- Buddy
[1] http://use.perl.org/~schwern/journal/39974
[2] https://github.com/gitpan/Data-Random
David Precious
> Guys,
>
> So, I found a bug in a CPAN module that hadn't been updated in some
> time. After I submitted a bug in RT, I checked the author's other
> modules and his RT tickets: no activity in years. So I sent the
> author an email, and said, hey, if you don't want to mess with this
> module any more, I'd be happy to take it over for you. And, voila,
> I'm now the proud(?) maintainer of Data::Random.
>
> So I need to create a repo for the code, and it would be nice to start
> with the previous versions, right?
knocking around he'd be willing to share with you, so you can maintain
history?
If not, you could probably cherry-pick commits from gitpan to your new repo to
get the previous releases there.
I'm not entirely sure that would be worth the effort, though; there's only 4
prior releases, and the real value in having the history in version control is
commit messages with explanations of decisions made and stuff, which you won't
have if you just have the snapshots of releases from gitpan.
Personally, I think I'd just import the current version into your new repo,
with a commit message making it clear that this is the current state of the
module and that you're taking over maintainership, then go from there. (and
that previous versions are of course available from backpan or gitpan, for
anyone who is interested)
Cheers
Dave P
--
David Precious ("bigpresh")
http://www.preshweb.co.uk/
"Programming is like sex. One mistake and you have to support
it for the rest of your life". (Michael Sinz)
Aristotle Pagaltzis
> a repo knocking around he'd be willing to share with you, so you can
> maintain history?
> I'm not entirely sure that would be worth the effort, though; there's
> only 4 prior releases, and the real value in having the history in
> version control is commit messages with explanations of decisions made
> and stuff, which you won't have if you just have the snapshots of
> releases from gitpan.
extra history around takes no space to speak of. I don’t really see the
point of *not* doing it, considering how little effort it takes with the
tools we have nowadays.
Regards,
--
Aristotle Pagaltzis // <http://plasmasturm.org/>
Buddy Burden
Yanick,
>> What I'm
>> wondering is, couldn't I just fork the gitpan repo for Data::Random[2]
>> and have that become my repo? Obviously I would never plan on merging
>> it back, but that shouldn't matter, I don't think.
>
> is no problem: anybody cloning or forking your project will only see
> the original commits as part of your repo history, and no-one will
> ever be the wiser.
Okay, that's the main thing I was wondering. I didn't know if somehow
GitHub would consider my repo to be a fork forever-more and that might
somehow have negative side-effects. I didn't think so, but I figured
it couldn't hurt to ask.
> Or, if you want to clone the gitpan repo the easy way:
>
> $ git cpan-import --gitpan Data::Random
Interesting ... are there advantages to that method over just forking gitpan?
-- Buddy
Buddy Burden
> Out of interest, did you try asking the original author whether he has a repo
> knocking around he'd be willing to share with you, so you can maintain
> history?
message very short and not ask for much. From my Googling around
while searching for a valid email address, I could see that he no
longer appeared to be programming (he is, in fact, the CEO of
Formspring[1]), so I figured the briefer and more to-the-point my
message, the better chance I had of not getting relegated to the spam
bucket. Also, I figured that, since the latest version is from 2002,
whatever repo he might have (if he still had it) would have to be
converted to git anyway[2], so why not just use the gitpan version?
Anyway, that was my thinking.
-- Buddy
[1] http://www.formspring.me/
[2] As, you know, git didn't exist yet back then.
Buddy Burden
> It’s still useful to be able to get diffs. And with git, keeping that
> extra history around takes no space to speak of. I don’t really see the
> point of *not* doing it, considering how little effort it takes with the
> tools we have nowadays.
-- Buddy
Yanick Champoux
>> > That would be the simplest way to go. That you would never merge back
>> > is no problem: anybody cloning or forking your project will only see
>> > the original commits as part of your repo history, and no-one will
>> > ever be the wiser.
> Okay, that's the main thing I was wondering. I didn't know if somehow
> GitHub would consider my repo to be a fork forever-more and that might
> somehow have negative side-effects. I didn't think so, but I figured
> it couldn't hurt to ask.
If forking directly from Github, people will see that it has been
forked from gitpan/Data-Random in the network view, but I can't see how
it could stigmatize your project. If the META.json of the distribution
is correctly set, peeps will know that you hold the main repo. If
anything, it might help people find your repo if they find the gitpan
version first (as they will see it in its own network). In any case, I
don't think it's a huge deal that would bring terrible consequences
either way. :-)
>> > $ git cpan-import --gitpan Data::Random
> Interesting ... are there advantages to that method over just forking gitpan?
Not really. It's just a quick, cli-alternative to clone the repo
locally. There Is More Than One Way To Fork It, I guess. ;-)
Joy,
`/anick
Aristotle Pagaltzis
> forever-more
If you really don’t want that, you can avoid it by cloning the GitPAN
repo with git, creating your a new repo on Github, and then switching
the `origin` URL of your clone to your own repo URL and pushing it.
> and that might somehow have negative side-effects.
Salvador Fandino
I have even done it for several of my own modules when they needed some
updating after years of being untouched and I was to lazy to go
recovering them from my old archived subversion repository.
Most modules are just not so complex to make having the full history
available such a critical thing.
Buddy Burden
On Mon, Nov 14, 2011 at 3:03 AM, Salvador Fandino <sfan...@yahoo.com> wrote:
> Forking from gitpan is a fine plan!
out there, after tracking down some problems in the test files that
CPAN Testers was thoughtful enough to catch for me.
Thanx everyone for the good advice!
-- Buddy