Re: Pull request template for github mirror

[Lasse Schuirmann <lasse schuirmann gmail com>]

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

contact viperdev io
http://viperdev.io/


2016-02-27 15:12 GMT+01:00 Jehan Pagès <jehan marmottard gmail com>:
> 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.
>
> Jehan
>
> --
> ZeMarmot open animation film
> http://film.zemarmot.net
> Patreon: https://patreon.com/zemarmot