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 <nsla...@apache.org> 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 <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 > -- NS
