couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Garren Smith>
Subject Re: [DISCUSS] Send Github new comment notifications to the dev list
Date Mon, 18 Mar 2013 07:32:56 GMT

On 17 Mar 2013, at 2:02 PM, Jan Lehnardt <> wrote:

> On Mar 17, 2013, at 04:58 , Randall Leeds <> wrote:
>> On Sat, Mar 16, 2013 at 6:27 PM, Nathan Stott <> 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
> -- 

View raw message