Re: Mirroring GNOME on github

[John Stowers <john stowers lists gmail com>]

>
> I'm just saying that we need maintainers to manually look at GitHub
> every once in a while for pull requests, and file a bug upstream or
> merge into the repo or something. Maintainers are already overworked,
> so I doubt they're going to do that.

See at end.

> The other alternative is telling everyone that files a pull request
> "this is not the appropriate mechanism for contributing back
> upstream",

This is Linus's position. I don't see it as a problem (although I
would replace 'appropriate' with 'preferred').

> even politely, is a turn-off. Are they going to make the
> effort to register at Bugzilla and learn how to use git-bz? I don't
> think so.

Probably not - that is my premise; they are using github because they
don't like/know the bz+git-bz workflow.

Would such a hypothetical contributor have bothered giving me the
laborious opportunity to reject his contribution if I had asked him to
go through bz first anyway?

If a contributor already has a github account, and a local git branch,
I can't honestly say that the most efficient way for him to contact me
is to install git-bz, magic it, set up a bz account, and magic the
diff into bugzilla. The magic is technically cool, I love git-bz, but
we are too inside the bubble to see that this is fcrazy for a moderate
newcomer (hello GSOC/GWOP)!

>
> But will the contributors forks and patches be respected? If we don't
> make an effort to upstream contributions from GitHub (which is manual
> effort), their time is wasted, and all we've done is put up a trap for
> potential contributors to fall into, where what they should have done
> was to file a bug and patch upstream.

I guess I replied above to this.

> It also means that we're maintaining two separate infrastructures --
> one on git.gnome.org, and one on GitHub. Fragmentation is never good.

Well Alberto can chime in here, but this should be automatic. We have
the metadata to route the branch/pull request mails to maintainers via
the doap files anyway.

We already have fragmentation on github, but because we are not a
canonical upstream there we cannot see the fragmentation via the
github network view.

John