couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <>
Subject Re: Comments threads on Github
Date Fri, 15 Mar 2013 23:20:44 GMT
I agree Benoit. This sounds like a better workflow for the project.

All I am saying is that if people want to use Github anyway, I don't think
we can stop them. And I don't think we should try. I think we should be
making it as easy to contribute to CouchDB as possible, and that includes

Perhaps while Jan works on this script so that Github comments get sent to
the ML, you could work with Paul to document an email based workflow. Then
we can document both ways of contributing to CouchDB, and state our
preference also.

On 15 March 2013 23:17, Benoit Chesneau <> wrote:

> On Fri, Mar 15, 2013 at 4:03 PM, Noah Slater <> wrote:
> > Benoit, that is the whole point of this thread. Making sure that Github
> > does *not* become the sole location of important development
> discussions. I
> > am trying to make the *current situation* better. I am proposing a
> solution
> > that would turn Github pull requests into something that would work
> > *exactly* like Review Board is working for other apache projects. That
> is,
> > it turns it into a code review tool. With *all of the discussion being
> > copied to the dev list*.
> >
> > I would be -1 on disabling PRs in Github. We can't do it anyway. We would
> > have to stop mirroring to Github, because Github doesn't allow you to
> block
> > PRs. And I think people are going to mirror and fork on Github anyway.
> >
> > We *cannot* prevent people from using Github. Git is a *decentralised*
> VCS,
> > and people will work with our code wherever they feel like that that is
> > *totally fine*.  All I am suggesting is that we improve the situation
> *for
> > us* by copying discussion here.
> The point is not to prevent them to use github. If they find
> themselves confident to use it this is fine. I'm only speaking about
> the way the code and patches should be submitted to the Apache CouchDB
> project. And it's perfectly fine to assume that their could be only
> one way to do it. Like you said git is decentralized. But that doesn't
> mean we don't need at some point to collect the patches and put the
> work on one point before deciding it can be merged.
> Having such workflow :
> dev A works on his branch on github
> dev B contact A and start to work with him with PR
> dev C do the same
> (Note that at this is point A is central to B and C but not for
> couchdb until he send us a patch by email or by submitting it to jira.
> is quite similar to
> dev A works on a branch and decide to share its patchwith others by
> formatting a patch and sending to the dev@ ml
> dev B decide to improve it, works on his branch and decide to send a
> new patch, format it and send it to the @dev ml
> dev C include it to its own work (am..) and format a new patch and
> send it to the @ml
> dev A include this new change as well, and resend a new patch to dev@
> with its own modifications.
> though the last is really decentralised  The ml is used as an hub to
> notfify others about changed and eventually discuss on it. Thsi hb has
> also the advantage to be read by others. They could also decide to
> work on it too without having to subscribe to an external service. It
> has also the advantage to put all the informations in a hub controlled
> by the apache foundation and will make sure it exists for a long time.
> - benoît
> - benoît


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message