On Tue, Apr 21, 2015 at 7:08 PM, Nick Dimiduk <[email protected]> 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 <[email protected]> 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 <[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. >> >> >> >> >> >
