On 05/22/2015 09:19 AM, Daniel P. Berrange wrote: > On Fri, May 22, 2015 at 09:11:09AM -0400, Cole Robinson wrote: >> On 05/22/2015 08:38 AM, Jiri Denemark wrote: >>> On Fri, May 22, 2015 at 08:20:31 -0400, Cole Robinson wrote: >>>> On 05/22/2015 03:33 AM, Peter Krempa wrote: >>>>> On Thu, May 21, 2015 at 21:34:25 -0400, Cole Robinson wrote: >>>>>> Hey all, >>>>>> >>>>>> Anyone considered setting up libvirt*.git mirrors on github? Given the >>>>>> popularity of github these days, IMO it's unfortunate we don't have an >>>>>> official mirror on there. >>>>>> >>>>>> As far as the actual mirroring though, we'd probably need to set up hooks on >>>>>> libvirt.org to push new commits up to github, there doesn't appear to be any >>>>>> better way than that. >>>>>> >>>>>> Thoughts? >>>>> >>>>> I'm worried that once we have a github clone that is described as >>>>> official it will motivate people to send code via github pull requests >>>>> rather than via the mailing list. >>>>> >>>> >>>> Yes that t seems to happen with many other projects that don't use >>>> pull-requests. However it's easy to catch these: libvirt committers can just >>>> 'watch' the github repo and get email notification when there's pull-request >>>> activity (I wish there was a way to send these notifications to a mailing list >>>> but github doesn't have native support for it: >>>> https://github.com/github/github-services/issues/804) >>> >>> No, please. Having to go to a github web page to see the pull request >>> and review and comment on it there is not something we want to do IMHO. >>> We don't want to have reviews and discussion in two places. Not to >>> >>>> That said I think pull-requests are still an opportunity to get new >>>> contributers, if we react quickly and point them at the mailing list and tell >>>> them they don't even need to subscribe, just git send-email it. >>> >>> Oh, so you only want it to get notifications so that we can redirect >>> them to a mailing list. I don't object if you want to do it, but I'm >>> certainly not going to be that kind of interface. I think it's enough we >>> already have bugzilla which is sometimes used for submitting patches. >>> Our contributor guidelines are pretty clear about the way to properly >>> send patches. >> >> right, I'm saying just point people at the mailing list/our guidelines without >> commenting on the code. infact it should be easy to setup a script that >> watches for this and automatically closes new pull-requests with a stock >> comment. FWIW I don't want to do my code review in a webapp either, and having >> to watch for pull-requests is annoying but github doesn't provide anyway to >> turn off the pull-request option. >> >> However my point still stands that it's a good opportunity to get new >> contributors. I can't really tell if anyone sees the benefit of adding a >> github mirror so I'd like to elaborate a bit. The summary is that any github >> presence lowers the barrier of contribution for a _fast_ growing percentage of >> developers. >> >> For better or worse a serious chunk of the new generation of open source >> contributors basically only know github and its workflow... and practically >> every new opensource project is built around github's workflow, so the balance >> is only going to shift over time. For some of those new folks I know for a >> fact that 'not on github' might as well be 'project uses bzr/cvs/svn' WRT >> barrier to contribution. However there's a few parts to it: >> >> 1) There's a repo on github that they can fork and add changes to: this is >> what we would add. For people that live in github, this means they can fork >> the repo under their account using their standard workflow (command line tools >> or a button in the web UI), push changes to their fork, and have it show up >> under their tickboard (which is _real_ motivation since github account pages >> are becoming the defacto 'open source resume' for said contributors) >> >> 2) They can submit a pull-request and have their code integrated into master: >> we wouldn't be doing this, just closing pull-requests straight away. However, >> for people that don't read our docs and submit a pull-request, I'm guessing we >> can still get them to send their patch to the mailinglist if they've already >> gone through the effort of writing it. That's been my experience watching >> pull-requests in qemu's github mirror, as long as you respond in a timely >> manner people will follow up to the mailing list. >> >> There's also the fact that in the linux virt space libvirt is basically the >> only major project without official representation on github: qemu, xen, >> ovirt, openstack all have github mirrors. libguestfs uses github as its >> primary repo, but not its issue tracker or pull-requests. Also lots of stuff >> in the container space like lxc/lxd, docker, kubernetes, openshift use github >> natively. Even many long existing open source organizations have github >> mirrors like libreoffice, apache, gnome. > > I've no real objection to us having an automated read-only mirror on github, > if we clearly direct people to the right place - if people want to ignore > the github account that's fine. > > Whether we should let pull requests get automatically spamed to the mail > list I'm ambivalent. If they are fairly infrequent, it probably isn't a > real burden to go to the list. If it does become a problem we can easily > turn it off, or have to just to go peole who wish to deal with it. > To clarify there isn't any current way to make this work AFAICT, short of standing up our own webservice somewhere as a github webhook. So no need to worry about that. Once the repos are up, if anyone wants to help watch for pull-requests, you can just 'watch' the repo and you'll receive email notifications when new pull-requests come in (might need a tweak in your github settings to set up how notifications are delivered, I can't remember exactly) > Since I already own the gitlab.com account for this, I might as well own > the github.com account to and set them up to use the same sync process. > > [1] https://gitlab.com/groups/libvirt > Cool, thanks. I'd like access to be able to close pull-requests, but I don't know if permissions can be that fine grained... - Cole -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list