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:07:41 GMT
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 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


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