htrace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin P. McCabe" <cmcc...@apache.org>
Subject Re: [DISCUSS] Release for HTrace/Drive Towards Graduation
Date Fri, 30 Oct 2015 19:43:23 GMT
There are a bunch of unresolved issues with github pull requests.
First, they create a bunch of merge commits which make the revision
history ugly.  More than just aesthetics, though, these spurious merge
commits break testing frameworks like Apache Yetus, and also our
internal release tools at Cloudera.  This is technical issue we'd have
to solve before going to that kind of system.

I definitely agree that posting patches is harder than it ought to be
with the attachment-based system.  Elliott has made this point as
well.  We could move to a gerrit-based system to address these issues.
I used gerrit when working on the open-source Android project, and we
use it internally at Cloudera.  It doesn't have the issues with merge
commits that GH has, and you can post a patch from the command line
just using git push, which is pretty cool.

I do think we will always want jira... for example, perhaps we could
set up a hook requiring gerrit requests to have a jira number, and
mirror the comments to there.  That preserves the history of our
project and prevents duplication.

It's a little unfair to say that we have no automated testing, since
we do have postcommit testing via Docker and it works pretty well.
Our tests also complete in < 3 or 4 minutes which makes it pretty easy
to run locally.  (A property which, by the way, we should work hard to
preserve...)  I agree that with gerrit we could have automated
precommit testing as well which would be even better.  Sometimes I
think having people run tests locally finds things we wouldn't find
with a central test system.  Masatake seems to hit valid unit test
bugs that I never do-- classpath stuff, race conditions, etc.

regards,
Colin

On Fri, Oct 30, 2015 at 10:45 AM, Adrian Cole <adrian.f.cole@gmail.com> wrote:
> Just one person, but I find the jira process arduous, as it forces
> commodity labor on the contributor.
> Even when the person remembers how to work with Jira patches, not everyone
> wants to relive that.
>
> I suspect I'm not the only one who finds the creating and rebasing patches,
> lack of automated patch testing via Travis, and the less user friendly diff
> view just undifferentiated work.
>
> I have a couple things on my laptop I haven't gotten around to submitting
> solely because of this pain. I don't think avoiding github helps anything
> except reduce those who want to contribute.

Mime
View raw message