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] Github integration
Date Wed, 22 Apr 2015 02:13:34 GMT
On Tue, Apr 21, 2015 at 7:08 PM, Nick Dimiduk <ndimiduk@apache.org> wrote:
> I would associate the upswing in introductions to increased marketing from
> joining incubator; orthogonal to moving out of github.
>
> No one has suggested moving away from patches attached to JIRA. As I said,
> patch on JIRA is what we'll eventually need for pre-commit checking anyway.
>
> I'd like the github mirror to be activated, which Jake has done. I'd also
> like PR's to show up as a mail to the dev list and, if possible, also land
> on the associated JIRA as a comment. I maintain that this will make it
> easier for non-Apache folks who fork-and-PR to get our attention without
> much fuss on either end.
>
> Does your -1 apply to PRs resulting in a mail on the dev list?

I think the minimum it would need to be usable to me would be some
kind of integration with JIRA, so that I could review the patch there.
I suppose we could set up some kind of system whereby comments made on
github were mirrored to JIRA.  I also don't think we should activate
any of this stuff before we have consensus on all the issues involved.

Colin


>
> -n
>
>
> On Tuesday, April 21, 2015, Colin P. McCabe <cmccabe@apache.org> wrote:
>>
>> The argument keeps getting made that we have to be on github "to make
>> it easy for outsiders to contribute" but I don't see any evidence to
>> back that up.  Quite the contrary, during the time HTrace was a github
>> project, the number of contributions and contributors were much
>> smaller than now.
>>
>> Objectively, the JIRA workflow is not difficult to learn.  The number
>> of new and recent contributors that Hadoop has is a testament to that.
>> And many other very successful projects use the same model.  I would
>> argue that to the average developer, attaching a text file to a JIRA
>> is easier to understand than creating a branch and a pull request in
>> github.  It's certainly easier for a first-timer than the upload
>> process of reviewboard or gerrit.
>>
>> I think if we are being honest with ourselves, the only valid reason
>> to switch away from patch attachments on JIRA is the convenience of
>> developers.  Elliot has said that he doesn't like having to click on
>> "attach patch."  Some things that haven't been brought up, but which
>> ought to be, are that reviews in JIRA require some cut-n-paste, and
>> that you need to install a Google Chrome extension to see side-by-side
>> diffs.
>>
>> My opinion is that while these things are kind of annoying, they're
>> really not that bad.  Having to explain what the difference is in my
>> latest patch versus the previous one takes much more time and mental
>> effort than clicking on "attach patch."  There are even scripts out
>> there to automatically attach patches.  Copying a few lines to the
>> clipboard to suggest changes during a review isn't bad... in some ways
>> I prefer it to clicking all those "expand discussion" arrows in other
>> code review tools.
>>
>> Colin
>>
>> On Tue, Apr 21, 2015 at 6:18 PM, Nick Dimiduk <ndimiduk@apache.org> wrote:
>> > There's a joke here about N devs in a room and N opinions that are all
>> > right
>> > (and all wrong)!
>> >
>> > 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.
>> >
>> > 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).
>> >
>> > I think the Apache infra allows comments on PRs that are tied to a JIRA
>> > to
>> > land in the comments on the associated JIRA. Is that right Jake? It
>> > doesn't
>> > prevent the patch from disappearing from github, but at least the trail
>> > of
>> > discussion is preserved and the "single page scroll down" consumption is
>> > still possible. I think we as a project can make it a policy that a
>> > patch
>> > must be attached to the JIRA, not just living in a PR (we'll want that
>> > for
>> > pre-commit build bot support anyway, right?) Use the PR as another means
>> > of
>> > review, not the source of truth on the the change itself. Would that be
>> > enough for you Colin?
>> >
>> > On the topic of Gerrit, there was a discussion about bringing it about
>> > for
>> > Apache projects. It's been raised and died and raised a number of times.
>> > Gerrit for reviews and push gating + github style build hook detection
>> > would
>> > be a great setup for me as well. Maybe we should investigate that as a
>> > separate thread?
>> >
>> > -n
>> >
>> > On Tue, Apr 21, 2015 at 6:07 PM, Elliott Clark <eclark@apache.org>
>> > wrote:
>> >>
>> >> For me pull requests show great history for the issue if things don't
>> >> get
>> >> bounced around too many different creators. Github really struggles
>> >> when
>> >> there are issues that hang around for a long time, either because they
>> >> don't
>> >> have patches yet, or because lots of different people are creating
>> >> candidate
>> >> patches. However for me email copies of everything that's from github
>> >> provide all the search-ability that I would need to just use github.
>> >>
>> >> However for me Jira is just so disconnected from the code that it's a
>> >> total time sink. I want to create code, look at code, and have my code
>> >> tested.  Every time I have to create a patch and attach it it's a total
>> >> context switch (better than RB but that's not saying much). The
>> >> integration
>> >> of jira and jenkins just feels like duct-tape and hope when compared to
>> >> the
>> >> hooks provided by github. So for me jira seems bad at creating patches,
>> >> reviewing patches, and testing patches.
>> >>
>> >> I've used gerrit before and it's awesome. Just a joy to use once things
>> >> are set up and moving. However I don't think that it will work since
>> >> it's
>> >> not supported by infra and it needs to be the source of truth for a git
>> >> repo.
>> >>
>> >> My preferences, in order, would be
>> >>
>> >> * Gerrit
>> >> * Github only
>> >> * Github with Jira integration
>> >> * Phabricator with jira
>> >> * Review board
>> >> * Jira only
>> >>
>> >> On Tue, Apr 21, 2015 at 5:19 PM, Colin P. McCabe <cmccabe@apache.org>
>> >> wrote:
>> >>>
>> >>> Pull requests aren't a replacement for JIRA, because they don't allow
>> >>> you to see the history of an issue over time, link it to other issues,
>> >>> post pictures or other observations, talk to the community, and so on.
>> >>> In a word, github isn't a bug tracker.  And the bug tracker that
>> >>> github does offer is very inadequate... even projects that go entirely
>> >>> github usually use an external bug tracker for this reason.
>> >>>
>> >>> I agree that reviewboard is a bad experience.  The big issue with RB
>> >>> has always been that it's clunky to post patches.  With JIRA, for all
>> >>> it's faults, I just click "attach file," select the file, and go.
>> >>> With RB, I have to fill out a form reminiscent of an IRS 1040 every
>> >>> time I post a patch.  Yes, I realize there are uploader scripts.  But
>> >>> after my uploader script broke the third time, I just decided it
>> >>> wasn't worth it and used the RB interface from then on.  I just don't
>> >>> have time to debug uploader problems, especially things like "you
>> >>> forgot to use --full-index, now I'm going to say 'file doesn't exist
>> >>> in project'"
>> >>>
>> >>> Jake, can you go into more detail about how Crucible is "slow and
>> >>> painful to use"?  Do you mean that the interface is not responsive?
 I
>> >>> haven't used Crucible before, but I would be up for evaluating it.
>> >>>
>> >>> I would be up for evaluating gerrit IF we had a plugin that mirrored
>> >>> the gerrit comments to JIRA so that they were indexable and searchable
>> >>> through normal means.  I have used gerrit before.  It offers a great
>> >>> uploading experience (just do "git push"), a GUI for making comments
>> >>> on patches, and the ability to submit a patch with one click.
>> >>>
>> >>> Colin
>> >>>
>> >>> On Tue, Apr 21, 2015 at 4:37 PM, Elliott Clark <eclark@apache.org>
>> >>> wrote:
>> >>> >
>> >>> > On Tue, Apr 21, 2015 at 3:34 PM, Jake Farrell <jfarrell@apache.org>
>> >>> > wrote:
>> >>> >>
>> >>> >> I'm a fan of reviewboard and think that the
>> >>> >> projects that have used it have had little issues with it
>> >>> >
>> >>> >
>> >>> > Uggggh review board's never been a good experience for me. If I
had
>> >>> > my
>> >>> > druthers I'd go all github all the time. Drop jira completely.
For
>> >>> > me
>> >>> > the
>> >>> > pull requests ui is just much closer to how I work.
>> >>
>> >>
>> >

Mime
View raw message