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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> wrote: >>> > >>> > On Tue, Apr 21, 2015 at 3:34 PM, Jake Farrell <[email protected]> >>> > 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. >> >> >
