I could see having a script that keeps BZ and GH in sync and if a participant tries it the second time just telling him that he please should register a BZ account (your proprietary trial is over ;)).
My vision of this "sync" is actually a complete sync: a comment on BZ happens -> will get mirrored to GitHub. A comment on the patch happens -> will get mirrored as a commit comment. Same the other way round. User pushes/force pushes new patches, old will be marked obsolete and the new ones will be attached. Sincerely, Lasse Schuirmann cont...@viperdev.io http://viperdev.io/ 2016-02-27 15:12 GMT+01:00 Jehan Pagès <jehan.marmott...@gmail.com>: > 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
