On Sat, Feb 27, 2016 at 6:12 AM Jehan Pagès <jehan.marmott...@gmail.com> wrote:
> 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. > 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
_______________________________________________ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
