On Mar 18, 2013, at 08:48 , Simon Metson <si...@cloudant.com> wrote:
> +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) I talked this one through with Paul Davis at ApacheCon EU and we concluded that it would be non-trivial to account for edge-cases. That said, if someone presents working sync scripts, we can talk to infra about running them. Jan -- > > > On Monday, 18 March 2013 at 07:32, Garren Smith wrote: > >> >> On 17 Mar 2013, at 2:02 PM, Jan Lehnardt <j...@apache.org> wrote: >> >>> >>> On Mar 17, 2013, at 04:58 , Randall Leeds <randall.le...@gmail.com> wrote: >>> >>>> On Sat, Mar 16, 2013 at 6:27 PM, Nathan Stott <nrst...@gmail.com> 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 >>> -- >>> >> >> >> > >
