develooper Front page | perl.perl5.porters | Postings from August 2013

Re: the GitHub perl mirror

Thread Previous | Thread Next
From:
Christian Walde
Date:
August 19, 2013 12:14
Subject:
Re: the GitHub perl mirror
Message ID:
op.w12carhnydyjqt@digitizedsqueak
On Sun, 18 Aug 2013 02:42:32 +0200, Karen Etheridge <perl@froods.org>  
wrote:

>> Unless it is discouraged, I would most likely start using this mechanism
>> (pull requests to github) preferentially to send patches, as currently I
>> find it rather a PITA to create a patch and submit it via perlbug, so  
>> for
>> small fixes I usually don't bother.

On Mon, 19 Aug 2013 12:26:04 +0200, Nicholas Clark <nick@ccl4.org> wrote:

> "push button merge" system

There is a misunderstanding here.

Ether would like to use the github interface to CREATE AND SEND patches.  
If you take the time and compare the mechanisms this seems entirely  
rational to me, since quite frankly, from a human interface point of view,  
the current method to send patches is much too large and complicated. It  
requires figuring out the right tools to use, the right incantations to  
use, creating the right text files, praying that one's OS didn't mangle  
them somehow, then praying that the email relay chain doesn't mangle them  
somehow and the only point at which one gets an indication of whether it  
worked correctly or not is when the patch hits the mailing list. And  
lastly, on top of that is the overhead of remembering all that stuff for  
the next time when one wishes to correct a spelling mistake in a readme.

Meanwhile to create a pull request, all one does is push the branch to  
one's own fork and click a button.

That's only for the creation side.


For the ACCEPT, VALIDATE AND INTEGRATE phase you're entirely right that  
github issues should not be used. As you mention, the way github merges  
things is useless, and discussion needs to happen on p5p/perlbug for  
archival reasons. It should be noted though that Github will detect  
merges, explicit or fast-forward, and close pull reqs automatically, so  
interaction with the close button is only necessary for rebases or  
rejections.


Note though that Ether never asked for that though, but only to be allowed  
to create trivial change requests in a trivial manner.

Isn't Perl all about "Make easy things easy and hard things possible."?

-- 
With regards,
Christian Walde

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About