couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: Comments threads on Github
Date Fri, 15 Mar 2013 22:54:56 GMT
On Fri, Mar 15, 2013 at 3:34 PM, Noah Slater <> wrote:
> On 15 March 2013 22:24, Paul Davis <> wrote:
>>  I'm personally fine with enabling as much
>> collaboration via GH as possible but its important to understand that
>> on multiple fronts it is not and can not be the central hub of
>> development for an Apache project.
> This is a strawman.
> On 15 March 2013 22:27, Paul Davis <> wrote:
>> I dunno. I was just pointing out that I wasn't optimistic that it
>> would be an acceptable mode of communication.
> It's an iterative improvement on the status quo, and unless anyone has any
> better ideas, I think we should go with it until a more obvious solution
> presents itself.
> --
> NS

Well, I don't think it's really a good idea to have multiple canal to
find patches and comment on patches. As a developer my attention is
limited to some canals, and I don't know a lot of project that does
have different canals for the code. Also what about search ? What if
the next time I have to find the reasoning abut a patch and couldn't
find it on one place?  It could alos be worth like having squashed
commits applied to our repo losing all the previous history and their
authors where if the work would have been done in a branch on our
repo, we would have everything.

Some projects like django tried for a long time to have 2 canals. At
the end they switched to only one. In their case github.

Also like Paul pointed it, git was designed with the mail support.It
has many tools to allow a workflow via mail (format-patch, am, ...) .
And btw, this is how works the linux project. It is relatively easy to
have git sending a mail with the patch to the ml. If associated with a
jira ticket in the commit msg then it would be added to that ticket

Imo we should disabled the github PR. Even if they are trendy among
some developers. It doesn't sound good to rely on an external service
to keep some part of the code history. And with a strong policy we
could have a very productive git-ml workflow. It would also give us
the advantage to have everything we want  under the hand rather than
having to jump from one service to another to find either the patch,
its update, the final version or the feedback on them. It could also
been used offline  since everything would be replicated on your disk.

- benoƮt

View raw message