| 1 |
On 13 September 2015 at 09:15, hasufell <hasufell@g.o> wrote: |
| 2 |
> Because that is not a valid bug report. Patches must be attached to |
| 3 |
> bugzilla. |
| 4 |
|
| 5 |
|
| 6 |
I would recommend against attaching the pull in patch form against |
| 7 |
bugzilla. It might lead to unintentionally misleading consequences. |
| 8 |
|
| 9 |
If the patch is automatedly filed against bugzilla, people will assume |
| 10 |
viewing that patch tells them all they need to know. |
| 11 |
|
| 12 |
But the reality is somebody may rebase/amend/repush to the publicised |
| 13 |
branch location before any developer reviews the patch in bugzilla, |
| 14 |
and so by the time somebody reviews the patch, it is already wrong. |
| 15 |
|
| 16 |
And as it is common for there to be a "get feedback, amend the pull, |
| 17 |
get feedback, amend the pull" loop in existing real-world git |
| 18 |
workflows, it should be assumed that is going to happen frequently. |
| 19 |
|
| 20 |
It would also be better for there to be some way to specify a |
| 21 |
repository remote and a ref-spec, not having github-intrinsic |
| 22 |
behaviours. ( Because people may have personally hosted git repos they |
| 23 |
want feedback on if they have a github aversion, and we must not |
| 24 |
*require* github to interact with the development workflow ) |
| 25 |
|
| 26 |
-- |
| 27 |
Kent |
| 28 |
|
| 29 |
KENTNL - https://metacpan.org/author/KENTNL |
Archives