On Sat, Sep 12, 2015 at 11:15:14PM +0200, hasufell wrote: > Because that is not a valid bug report. Patches must be attached to > bugzilla.
Right, thanks. In that case, I think you'll need a hook to push a new patch whenever the GitHub branch is updated, rebased, etc. That could make for a lot of Bugzilla spam, because folks tend to cycle less formally in GitHub branches than they do with list-based (and similar) workflows. For example, if I submit a patch series to a mailing list, I'll wait a week before pushing v2 with a bunch of typo fixes, etc. But if I submit a patch series via a GitHub PR, I'll push fixes for those sort of things immediately. I'm skeptical that you'll be able to retrain frequent GitHub users to pace their pushes, so hopefully this has a technical solution. Maybe iterate over open PRs every week and push changed patches to Bugzilla? That avoids too much spam, but it means that comments via GitHub and Bugzilla may be talking about different versions of the branch (which seems like it would cause trouble ;). Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
signature.asc
Description: OpenPGP digital signature
