couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Noah Slater <nsla...@apache.org>
Subject Re: Comments threads on Github
Date Fri, 15 Mar 2013 23:03:08 GMT
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 <bchesneau@gmail.com> wrote:

> On Fri, Mar 15, 2013 at 3:34 PM, Noah Slater <nslater@apache.org> wrote:
> > On 15 March 2013 22:24, Paul Davis <paul.joseph.davis@gmail.com> 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 <paul.joseph.davis@gmail.com> 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

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