Re: Pull request template for github mirror

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.

Lasse Schuirmann

contact viperdev io

2016-02-27 15:12 GMT+01:00 Jehan Pagès <jehan marmottard gmail com>:

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
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.


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

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.


ZeMarmot open animation film

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]