+1 on getting PR's into the work flow... But, is the dev@ list the right place to do it? Shouldn't we be looking at linking PR's to JIRA? Both systems have api's, I'd wager it'd be fairly simple to couple the two bidirectionally. (Apologies if this opens another can of worms)
On Monday, 18 March 2013 at 07:32, Garren Smith wrote: > > On 17 Mar 2013, at 2:02 PM, Jan Lehnardt <[email protected]> wrote: > > > > > On Mar 17, 2013, at 04:58 , Randall Leeds <[email protected]> wrote: > > > > > On Sat, Mar 16, 2013 at 6:27 PM, Nathan Stott <[email protected]> wrote: > > > > Just a CouchDB fan who has been using it since v0.8 here. I read this > > > > list > > > > a lot and want to chime in on this topic. To be blunt, those who are > > > > arguing to ignore pull requests or trying to keep Noah from taking his > > > > suggested steps are being obtuse. The tone of this discussion and the > > > > attitude towards pull requests from some contributors looks extremely > > > > bad. > > > > > > > > > > > > > I don't see anyone arguing for ignoring them. > > > > > > On the other hand, I very much sympathize with Benoit in many ways. > > > > > > There are two alternatives that I like. > > > > > > 1) Don't allow pull requests. I mean don't *allow*. As in, there is > > > literally no place to make one in the Github UI. > > > 2) PR comments to go to dev@. Replies to that thread become PR comments > > > somehow. > > > > > > If I get an email through dev@ about a PR I don't want to go to Github > > > to reply, I want to respond to the email. > > > > > > Number 2 is the best, IMO. But without *two way* sync, the discussion > > > doesn't feel smooth to me. In the absence of that, I would prefer no > > > pull requests than one-directional pull request*, and say "contribute > > > through these accepted methods". Unfortunately, I don't think the > > > first option is *possible*. Therefore, we cannot stop people from > > > making pull requests, and we can't ignore them, so one direction is > > > better than no direction. > > > > > > If we can't turn off the ability to make a pull request at all, I > > > think we go forward with comment sync and hopefully we get to full, > > > two-way sync real soon. > > > > > > * I hate the idea that someone can make a PR and, in order to respond, > > > one has to have a Github account. That feels like it violates the > > > spirit of our vendor neutrality. People can always discuss things > > > elsewhere (G+, Twitter, whatever), but to have an "official" channel > > > like apache/couchdb on Github and not discourage contributions through > > > that channel we should support it in both directions without pushing > > > everyone to use Github. > > > > > > > > > I 100% sympathise with the sentiment here. It feels technically and > > socially dirty to go with a one-way solution and I wish there was a > > know we can turn that makes it all work. > > > > Now, I think that handling PRs the way we do now is a *way worse > > offense* to contributing to CouchDB than getting mails to dev@ back > > to GitHub Pull Requests. Orders of magnitudes worse. > > > > So much so that I volunteer to manually copy all the emails that > > are sent in reply to a Pull Request to dev@ back to GitHub. > > > > > I think its really important to integrate with Github. Jan I'm happy to help > you with copying emails back to Github until we have a working solution. > > > > And yes, that sucks on a number of levels, but it gives us an 80% > > solution that doesn’t hurt anyone (except me, but I volunteer) for > > a problem that holds contributions to CouchDB back big time. > > > > Furthermore, I think two-way sync can be solved technically and I > > will have every incentive to make that work, my manual labour gets > > out of hand (heh). > > > > Finally, please stop bringing up vendor-neutralness. This is a non- > > issue here. The second GitHub starts acting in a way we don’t like > > it, we can drop everything. Again, this is an optimisation for sub- > > group of developers that helps the project overall without making it > > harder for anyone else using other means *and* it doesn’t put Apache > > CouchDB into a vender-lock-in situation down the road. > > > > Cheers > > Jan > > -- > > > > >
