[libvirt] official libvirt mirror on github?

[Cole Robinson]

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