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