Hi, On Sat, Feb 27, 2016 at 12:30 AM, Alberto Ruiz <ar...@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. Jehan -- ZeMarmot open animation film http://film.zemarmot.net Patreon: https://patreon.com/zemarmot _______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
