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.
- Cole