htrace-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin P. McCabe" <>
Subject Re: [DISCUSS] Github integration
Date Sun, 26 Apr 2015 20:45:19 GMT
When I was first getting started with open source development, the
de-facto standard hosting place was SourceForge.  It was never
perfect, but it provided basic web hosting, source control (in those
days, everything was svn or cvs), wiki, bug tracker, etc.

SourceForge had a lot of momentum in those days.  Somehow, though,
over the course of 10 or 15 years, things just went wrong for the
site.  It started requiring more and more clicks to download anything,
and more and more ads started popping up.  Now it's pushing malware
installers, at least according to this article on gluster's blog.

Other competitors popped to try to take on the mantle of best open
source hosting site.  Google Code (now shutting down), BitBucket, now
Github.  I've used 'em all.  I have repos hosted on SourceForge,
BitBucket, Github, and Google Code.  (Which reminds me, I have to
migrate the projects I still have on Google Code soon...)

What I found is that putting stuff up on github doesn't guarantee pull
requests, or really any kind of community engagement.  I think I've
gotten a grand total of 3 pull requests for my github repos over the
last 5 years.  And the repos that I got pull requests for were ones
that I gave talks on at conferences, or talked to co-workers about.
HTrace's own experience was similar... we had very few contributors
back in the github days.  In my experience, a quiet fade into
obscurity is the fate of most github projects.  Getting people
interested and contributing to projects requires stepping away from
the computer and interacting with them on a personal level, not
whiz-bang software.

I think the most important thing that github provides projects with is
a standard landing page, a standard way to contact the author, and a
standard way to send in patches.  If you are just perusing someone's
private website, it may not be obvious how to contact them or what
format to send the patches in.  Github alleviates that problem.  For
HTrace, we already have our own landing page, our own mailing list and
bug tracker, and our own conventions about how to send in patches.
Github adds a lot less value for us.

The idea that projects get popular because of where they host their
code or what software they use to do reviews seems really questionable
to me.  Some of the most popular projects, like the Linux kernel, have
really esoteric review systems (i.e. sending in carefully formatted
patches to a mailing list).  Hadoop is another example... we have a
lot of antiquated practices like CHANGES.txt, but still get a lot of

JIRA adds a lot of value for us because it lets us search discussions
that go back potentially years.  On Hadoop, I often find myself
referring to old discussions to see why something was done one way or
another.  I also use it to see what is in one release or another
release (it can search by version).  It can do searches across
multiple projects (In JQL terms, "project = hadoop or project = htrace
and ...")  JIRA is also a place where people can comment even if they
are not developers.  If they are users who just want to see something
fixed, they can comment on the jira asking what is going on with the
issue.  Or they can open a JIRA to suggest a feature, link one JIRA to
another, etc.  Yes, JIRA comments are mirrored to email, but the
mirroring is a pretty lossy process.  You can't search emails by
version, or across projects, or in any structured way.

If we can have github comments mirrored to JIRA as you describe, maybe
it's not so bad.  But it's not so good either.  Looking at that JIRA
conversation, I find it a bit harder to follow than a "standard" one.
The software seems to be quoting huge amounts of code context, making
it a little bit tougher to follow.  A human would have only quoted the
lines he was interested in.  And I wonder whether, if I made a comment
on the JIRA, the person would see it, or whether he'd only be
following the github.  In other words, is the mirroring two-way?

I don't know.  I have to think about this more.  If there is really a
huge demand by people outside the project to use github, and we have
JIRA integration, then maybe it could work.  So far all of the demand
seems to be from people who are already contributors.  This makes me
think that something like Crucible would actually be a better fit,
since it fits into our existing workflow rather than grafting a
3rd-party website to it.


On Sun, Apr 26, 2015 at 12:36 PM, Nick Dimiduk <> wrote:
> For reference, here's a ticket [0] from Phoenix which makes used of the
> Github PR integration. As you can see, the PR comments are posted on the
> JIRA. In this regard, it's actually easier to track patch comments than in
> RB, by simply looking at the JIRA comments.
> [0]
> On Fri, Apr 24, 2015 at 11:38 AM, Roman Shaposhnik <>
> wrote:
>> On Tue, Apr 21, 2015 at 6:18 PM, Nick Dimiduk <> wrote:
>> > There's a joke here about N devs in a room and N opinions that are all
>> > right (and all wrong)!
>> Isn't the lower bound on the number of opinions at least N^2?
>> > All I'm asking for here is to make it easy for outsiders to contribute.
>> > Having HTrace show up in the mirror is a big step. The next logical thing
>> > is folks will click the fork button. We should be ready to receive the
>> > incoming help; the details of that implementation are less important to
>> me.
>> That's all posible today.
>> > Whatever our individual opinions, GH is a defacto place for developers
>> > these days -- their tools are extremely well socialized. It's a shame to
>> > cut ourselves off from users of that community. I happen to share Colin's
>> > opinions about the inferiority of GH's interface for historical comments
>> (I
>> > personally like gerrit the best of the tools I've used), but that doesn't
>> > mean we should shun it. (I also generally loath JIRA, on par with
>> Elliott's
>> > thoughts).
>> FWIW: I have seen how enabling GH workflow helps increase
>> the # of meaningful contributions coming in. Apache Groovy (incubating)
>> is a prime example of a project that runs as close to pure GH workflow
>> as is possible within ASF.
>> Thanks,
>> Roman.

View raw message