> > 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 _______________________________________________ desktop-devel-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/desktop-devel-list
