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