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

Re: the GitHub perl mirror

Thread Previous | Thread Next
Nicholas Clark
August 19, 2013 12:25
Re: the GitHub perl mirror
Message ID:
On Mon, Aug 19, 2013 at 08:11:30AM -0400, Ricardo Signes wrote:
> * Nicholas Clark <> [2013-08-19T06:26:04]
> > The current implementation of pull requests sucks massively because it
> > generates trivial merge commits, when it could avoid this.
> Pull requests are great.  The merge button stinks.

Yes. Having a way to have pull requests end up in somewhere noticeable would
resolve most o this. But as you said, pull requests that "we" can't close is,
um, extremely unhelpful.

> > It also encourages merging without running tests.
> Travis CI integration ameliorates that.

but you still end up with crap in blead, which is supposed to behave like an
integration branch, and be in state of "tests pass". The resulting delay in
getting things fixed can mean that it's not in a viable bisect-able state.
And the history log is harder to read, because it ends up with 2 (or more)
commits, which could easily have been done as 1.

> > My understanding was that both git and the Linux kernel implement code
> > review quite successfully by mailing patches to the dev list. I think that
> > Ricardo has been keeping his eye open for code review tools (but he'll have
> > to confirm this or correct me when he's back.)
> Confirmed, more another time.
> > I don't think that it's really a toolchain problem that prevents us from
> > having code review. It's a combination of a lack of an existing culture of
> > doing this, a *massive* time constraint, and that the code is spread so
> > thinly that the chance of finding a second person already familiar with the
> > code is low.
> I agree, but the other issue is that it's a pain and unusual, imho, for users
> to have to build their branch into a patch series and send it in exactly the
> right way.  "I pushed to a remote and told you where it is" is a ton easier.

I'd infer that has to be a matter of opinion. In that for Linux and git
development to be working, then it implies that it's quite normal for Linux
and git patch submitters to know how to mail patches.

It also *ought* to be relatively easy to automate that whole "send it the
right way" given that the git plumbing needed to figure out *what* to show
in a pull request on a third party website is going to be the same git
plumbing as needed to figure it out locally. But that is infinitely more
work that something which exists already.

Still, pull requests that can't be closed suck immortally.

> It's what I tell people to do when I know I can review *right now* and everyone
> seems happy when they can stick to that.  That's a large part of what makes
> pull requests nice for submitters.

Not sure how much "*right now*" is key here.

> Museum time!

Have fun.

Nicholas Clark

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About