Hi,
On Sat, Feb 27, 2016 at 12:30 AM, Alberto Ruiz <aruiz gnome org> wrote:
> Perhaps I should jump in as I created the mirror alongside Andrea Veri.
>
> The mirror in general is quite useful, a lot of people fork projects and
> check them out automatically instead of checking them out from git.gnome.org
> and then pushing them in github. These contributions (there's about 200 pull
> requests, see link below) would likely not have happened if we didn't have a
> presence in Github. Shutting down the mirror would simply stop that energy.
>
> https://github.com/search?utf8=%E2%9C%93&q=type%3Apull+user%3Agnome+state%3Aopen
Ok.
> I do know it is not ideal to have unattended contributions, mind though,
> GitHub won't allow an option for disabling Pull Requests even though we
> asked for it. And I committed to not allow usage of PRs since we don't want
> to rely on a closed service for our operations.
>
> As per Thomas suggestion I think it's an overkill to modify every single
> repo. The real solution is to finish this script/hook that would find the
> right bugzilla product URL in the .doap file and create a bug in bugzilla
> automatically for the user. If we were able to then allow logins from
> github's OAuth into our bugzilla instance that'd be great as it would reduce
> friction.
If that means just creating a bugzilla ticket with the patch attached,
and closing the pull request, the problem is that we lose discussion
with the contributor. Even though we would add a message on the pull
request basically saying "we opened a bug report at this address,
please continue the discussion there", I noticed that many people who
would use github rather than the project's prefered method of
contribution (GNOME's bugzilla in our case) are simply reluctant on
creating a new account for some reason (as though they did not have to
do so for github, but somehow they consider this one a given). So we
could not ask them to modify the patch, etc. Basically I would be a
little scared we end up with tickets where the contributor never
answer to our patch modification requests, and we never close the
report nonetheless because the original proposition still made sense
(just quality, code logics, or whatnot are not acceptable just yet to
be merged in our tree). Basically more ghost bug reports. We already
have a lot of these on the GIMP project.
If that means "syncing" the github pull request and the bugzilla
ticket, as Lasse suggests, that's a little more useful, since we can
still have a dialog with the contributor without having him to create
an account. But in such a case, we should still make sure that
contributors understand this is not the prefered way of contributing,
by at least adding a message atop. Indeed the problem of the sync
solution is that we give legitimity to github pull requests. From
contributor's point of view, they become equivalent to making a ticket
on GNOME's bugzilla. So why would they ever make an account upstream?
Moreover how will it be possible to move tickets to another project
now (as far as I know, you cannot "move" a pull request)? Should we
start blocking bugzilla tickets when synced to a github pull request,
and thus limit ourselves to what github decides?
As such, as you say above, we would start "relying on a close service
for our operations".
These look like very difficult implementation decisions if we want to
keep usability (be able to discuss with contributors) while still stay
independent of github repos.
Depends on how much work the maintainer is willing to do to retain new contributors. Myself, I'd treat a pull request just like a patch that didn't follow the coding style; the first few times I'll just fix it up myself and thank the contributor, mentioning to please read the guidelines for next time. After a few contributions, when they are invested, then I have more leverage to ask that they do it in the preferred way, and it's less likely they'll think it's too much work and give up. You can use the same technique for getting people to move to Bugzilla.
As Lasse says this could be enforced by a script, but maintainer discretion goes a long way too :-)
Regards,
Philip C
