couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: Comments threads on Github
Date Fri, 15 Mar 2013 23:17:24 GMT
On Fri, Mar 15, 2013 at 4:03 PM, Noah Slater <nslater@apache.org> 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

Mime
View raw message