Re: license information and link to source code repository from your CPAN distribution

2013-01-08 Thread Olaf Alders

On 2013-01-08, at 1:31 PM, David Nicol wrote:

> 
> 
> On Tue, Jan 8, 2013 at 12:14 PM, Olaf Alders  wrote:
> > uh, CPAN /is/ a public version control system. You have a favorite VCS and 
> > want to make diffs easily? Download, unpack, init, add, commit, work, diff.
> 
> That doesn't sound easy at all.  ;)  For example, if you want to send a 
> simple doc patch to an author who has the source code on Github, you can 
> either jump through the hoops you're describing or
> 
> a) fork the project on Github
> b) edit the file in place on Github
> c) click the pull request button
> 
> That strikes *me* as much easier and you get built in request tracking.
> 
> actually, for a small patch without an explicit VCS framework, the 
> antediluvian workflow of unpacking twice, editing once, and using diff -U to 
> make the patch is a little simpler. Of  course you can't do that in a web 
> browser that I know of. At some point I switched to mercurial for such 
> one-offs, and as I'm still more comfortable with command line editing tools 
> than editing in place on Github, my workflow for editing something that's on 
> github still consists of checking it all out, editing it, then pushing it 
> back. I should look into editing in place with Github's web browser editor.

I totally get that this isn't a one size fits all proposition and I wouldn't 
want to impose my own preferences on others. I should also mention that, on the 
other side of the coin, the workflow to merge a pull request (one click) can be 
faster than manually applying a patch.  So, using something like this has the 
potential (in some cases) to make it easier for both parties.

Olaf
--
Olaf Alders
o...@wundersolutions.com

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

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



Re: license information and link to source code repository from your CPAN distribution

2013-01-08 Thread David Nicol
On Tue, Jan 8, 2013 at 12:28 PM, John M. Gamble  wrote:

>
> It was not intended as a constantly synchronized central repository of all
> of CPAN.
>

That's what I meant, and it was something of a straw man.


Re: license information and link to source code repository from your CPAN distribution

2013-01-08 Thread David Nicol
On Tue, Jan 8, 2013 at 12:14 PM, Olaf Alders wrote:

> > uh, CPAN /is/ a public version control system. You have a favorite VCS
> and want to make diffs easily? Download, unpack, init, add, commit, work,
> diff.
>
> That doesn't sound easy at all.  ;)  For example, if you want to send a
> simple doc patch to an author who has the source code on Github, you can
> either jump through the hoops you're describing or
>
> a) fork the project on Github
> b) edit the file in place on Github
> c) click the pull request button
>
> That strikes *me* as much easier and you get built in request tracking.


actually, for a small patch without an explicit VCS framework, the
antediluvian workflow of unpacking twice, editing once, and using diff -U
to make the patch is a little simpler. Of  course you can't do that in a
web browser that I know of. At some point I switched to mercurial for such
one-offs, and as I'm still more comfortable with command line editing tools
than editing in place on Github, my workflow for editing something that's
on github still consists of checking it all out, editing it, then pushing
it back. I should look into editing in place with Github's web browser
editor.


Re: license information and link to source code repository from your CPAN distribution

2013-01-08 Thread John M. Gamble
On Tue, January 8, 2013 12:14 pm, Olaf Alders wrote:
>
> On 2013-01-08, at 1:03 PM, David Nicol wrote:
>
>>
...

>
>>
>> On the other hand, a comprehensive "CPAN by git" as an additional CPAN
>> feature would have a measure of awesome to it, as an alternate
>> distribution and synchronization method.

I don't know what that means. What would this hypothetically entail?

>
> Well, there is GitPAN, but it needs a lot of love
> https://github.com/gitpan

Just to nip a possible misunderstanding in the bud, as far as I can tell
the purpose of gitpan was to help CPAN authors who were not on github get
on github, by starting their own accounts and forking their modules from
gitpan (which I did, by the way. Thank you, Schwern).

It was not intended as a constantly synchronized central repository of all
of CPAN.

So if you need a leg up on getting your modules over to a version control
system, gitpan is a very useful starting point.

 -john



Re: license information and link to source code repository from your CPAN distribution

2013-01-08 Thread Olaf Alders

On 2013-01-08, at 1:03 PM, David Nicol wrote:

> 
> > Recently I checked and only 50% of the CPAN distributions have a link
> > to a public version control system:
> > http://blogs.perl.org/users/gabor_szabo/2013/01/50-of-the-new-cpan-uploads-lack-a-repository-link.html
> 
> uh, CPAN /is/ a public version control system. You have a favorite VCS and 
> want to make diffs easily? Download, unpack, init, add, commit, work, diff. 

That doesn't sound easy at all.  ;)  For example, if you want to send a simple 
doc patch to an author who has the source code on Github, you can either jump 
through the hoops you're describing or 

a) fork the project on Github
b) edit the file in place on Github
c) click the pull request button

That strikes *me* as much easier and you get built in request tracking.  
Granted, not everyone uses Github, but it's a very minimal workflow.  What 
Gabor is saying is that *if* your dist is actually available via 
Github/Bitbucket etc, you should let people know so that they can help you out. 
 If you do include this in your Meta files, MetaCPAN will add a handy link 
right to your repo, which makes the process even easier.  So, it helps people 
be even lazier about contributing, which is a good thing.  If it doesn't 
scratch everyone's itches, that's OK too. At least, if you include your repo 
url, you're not making me search Github to see if your repo already exists 
there.

> 
> On the other hand, a comprehensive "CPAN by git" as an additional CPAN 
> feature would have a measure of awesome to it, as an alternate distribution 
> and synchronization method.

Well, there is GitPAN, but it needs a lot of love https://github.com/gitpan

Olaf

--
Olaf Alders
o...@wundersolutions.com

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

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



Re: license information and link to source code repository from your CPAN distribution

2013-01-08 Thread David Nicol
> > Recently I checked and only 50% of the CPAN distributions have a link
> > to a public version control system:
> >
> http://blogs.perl.org/users/gabor_szabo/2013/01/50-of-the-new-cpan-uploads-lack-a-repository-link.html
>
> uh, CPAN /is/ a public version control system. You have a favorite VCS and
want to make diffs easily? Download, unpack, init, add, commit, work, diff.
I do admit I've started experimenting with adding github repos for my
modules, but I'm not at all certain that it is any improvement, and
demanding that as a requirement seems unnecessary.

On the other hand, a comprehensive "CPAN by git" as an additional CPAN
feature would have a measure of awesome to it, as an alternate distribution
and synchronization method.

The converse interpretation of the data -- fully half of new CPAN uploads
contain a link
to a non-CPAN VCS -- seems like a valid cause for celebration, rather than
alarmed finger-pointing at the non-adopters.

dln


Re: license information and link to source code repository from your CPAN distribution

2013-01-08 Thread John M. Gamble
On Tue, January 8, 2013 10:43 am, David Cantrell wrote:
> On Tue, Jan 08, 2013 at 10:06:31AM -0600, John M. Gamble wrote:
>
>> I think the finger should be pointed at h2xs, at least as it stands now.
>> A
>> programmer new to CPAN won't know about the META information, and h2xs
>> just isn't oriented that way.
>
> I think the finger should be pointed at perlnewmod.pod, which
> erroneously suggests using h2xs even for non-XS modules.  It should just
> tell people to use module-starter.
>
> And even if it doesn't work on Windows because of the getpwuid thing,
> it's still better than using h2xs.
>

Well, I'm hoping this is a temporary problem. I've used module-starter
successfully a couple of years ago. I'm submitting a bug report now.

 -john




Re: license information and link to source code repository from your CPAN distribution

2013-01-08 Thread David Cantrell
On Tue, Jan 08, 2013 at 10:06:31AM -0600, John M. Gamble wrote:

> I think the finger should be pointed at h2xs, at least as it stands now. A
> programmer new to CPAN won't know about the META information, and h2xs
> just isn't oriented that way.

I think the finger should be pointed at perlnewmod.pod, which
erroneously suggests using h2xs even for non-XS modules.  It should just
tell people to use module-starter.

And even if it doesn't work on Windows because of the getpwuid thing,
it's still better than using h2xs.

-- 
David Cantrell | Bourgeois reactionary pig


Re: license information and link to source code repository from your CPAN distribution

2013-01-08 Thread John M. Gamble
On Tue, January 8, 2013 5:15 am, Gabor Szabo wrote:
> Hi,
>
> those of you who read blogs.perl.org probably already saw my posts,
> but I guess there are many others
> on this list who are not reading that site.
>
> Recently I checked and only 50% of the CPAN distributions have a link
> to a public version control system:
> http://blogs.perl.org/users/gabor_szabo/2013/01/50-of-the-new-cpan-uploads-lack-a-repository-link.html
>
> 17% don't have the license information in their META file:
> http://blogs.perl.org/users/gabor_szabo/2012/12/174-of-cpan-uploads-have-no-license-in-the-meta-files.html
>
> It would be nice if you could help improving the situation for your
> modules.
>

I think the finger should be pointed at h2xs, at least as it stands now. A
programmer new to CPAN won't know about the META information, and h2xs
just isn't oriented that way.

I can pass on the other META info (the module might be uploaded to CPAN
before the author even decides on a version control repository, for
example), but at a minimum h2xs should have been asking about license
information.

(I was going to compare and contrast with module-starter, which I have
used and recommend normally, but I just encountered this unpleasant
surprise:

C:\Users\jgamble\prj>module-starter --module=Bogus::Example
The getpwuid function is unimplemented at
C:/Perl64/site/lib/Module/Starter/Simple.pm line 97.

So I'm blocked there for a moment.)

 -john