couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Comments threads on Github
Date Fri, 15 Mar 2013 23:36:59 GMT
On Fri, Mar 15, 2013 at 6:07 PM, Noah Slater <> wrote:
> I would like to suggest that we bring this thread to an end. I know it is
> frustrating a few people, and it is certainly starting to show in my
> emails, and we're not really making any progress aside.
> I would ask that if you have any remaining questions about project
> governance or the Apache way, you start a separate thread on the ML, and we
> can discuss it there.
> If you would like to suggest that we take a step backwards and turn off our
> Github mirror, please also create a separate thread. (I am hoping nobody
> creates this thread.)

I'd just like to point out that no one has suggested anything anywhere
close to this. I'm sorry if you feel frustrated but I'd like to be
clear that I'm not being all angry at the keyboard over here or
anything. I do think I've been trying to make a very subtle point that
I probably haven't done the best job of illustrating it but I'm very
much in a "I'm trying to helpfully discuss how I understand things"
rather than rage typing what I think Things Should Be Like.

> I am going to start a separate thread about copying Github comments to the
> list, to see if we can establish consensus and move forward productively.
> On 15 March 2013 23:03, 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.
>> On 15 March 2013 22:54, Benoit Chesneau <> wrote:
>>> 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
>>> automatically.
>>> 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
>> --
>> NS
> --
> NS

View raw message