| 1 |
On Sat, 12 Sep 2015 21:12:25 +0200 Michał Górny wrote: |
| 2 |
> Hello, everyone. |
| 3 |
> |
| 4 |
> The current workflow for handling github pull requests is at least |
| 5 |
> suboptimal. Handling pull requests takes a fair effort from the few |
| 6 |
> developers contributing there, and the progress is often stalled by |
| 7 |
> package maintainers which are either unresponsive or not registered on |
| 8 |
> github at all. That's why I'd like to get your ideas on how we could |
| 9 |
> improve the workflow. |
| 10 |
> |
| 11 |
> |
| 12 |
> |
| 13 |
> Current workflow |
| 14 |
> ================ |
| 15 |
> |
| 16 |
> Let's summarize the current workflow first. Right now, there's a few |
| 17 |
> Gentoo developers who actively monitor pull requests on gentoo/gentoo |
| 18 |
> repository. Those developers review incoming pull requests and help |
| 19 |
> submitters get their contributions in shape. Some of those developers |
| 20 |
> also try to 'CC' (@-mention) package maintainers to get their attention |
| 21 |
> on the pull request. |
| 22 |
> |
| 23 |
> Sadly, @-mentioning sucks for a few reasons: |
| 24 |
> |
| 25 |
> 1. Many of the Gentoo developers have different nicknames on GitHub. |
| 26 |
> Some developers don't even set their real names which makes them even |
| 27 |
> harder to find. |
| 28 |
> |
| 29 |
> 2. Teams can be created only by repository 'owners' (which pretty much |
| 30 |
> is equivalent of Infra). Which practically means I'm the only person |
| 31 |
> migrating teams (projects, herds) to GitHub. |
| 32 |
> |
| 33 |
> 3. GitHub notifications are not very reliable. Some developers get only |
| 34 |
> some of them via mail, some don't. And some simply don't care. |
| 35 |
> |
| 36 |
> 4. Some developers openly refuse to work with contributors via GitHub. |
| 37 |
> Proxying them manually is not really productive. |
| 38 |
> |
| 39 |
> |
| 40 |
> |
| 41 |
> Potential solution: bi-dir github <=> bugzilla integration |
| 42 |
> ========================================================== |
| 43 |
> |
| 44 |
> My current idea would be pretty much that: |
| 45 |
> |
| 46 |
> 1. a new dedicated Gentoo bug would be automatically created for every |
| 47 |
> pull request on github, |
| 48 |
> |
| 49 |
> 2. all comments from github would be automatically copied to bugzie. |
| 50 |
> All bugzie comments would be automatically copied to github, |
| 51 |
> |
| 52 |
> 3. resolving the bug would automatically close the relevant pull |
| 53 |
> request. |
| 54 |
> |
| 55 |
> This way, all pull requests can be assigned to package maintainers in |
| 56 |
> Bugzilla without having to resort to GitHub user or team names. All |
| 57 |
> involved parties would get more reliable Bugzilla notification mails. |
| 58 |
> They could choose to either use the provided URLs to discuss the pull |
| 59 |
> request on GitHub, or discuss it directly on Bugzilla, whichever is |
| 60 |
> more convenient to them. |
| 61 |
> |
| 62 |
> The additional Bugzilla load should be manageable, though we may want |
| 63 |
> to employ some kind of rate limiting in case someone though it'd funny |
| 64 |
> to spam our bugzilla via spamming github. |
| 65 |
> |
| 66 |
> Problems: |
| 67 |
> |
| 68 |
> - handling line comments (probably a Bugzie comment with quoted code |
| 69 |
> snippet), |
| 70 |
> |
| 71 |
> - handling comment edits and removals, |
| 72 |
> |
| 73 |
> - some people will get double mail for each comment, |
| 74 |
> |
| 75 |
> - extra bugs for existing issues (we shouldn't really try to reuse |
| 76 |
> existing bugs for this). |
| 77 |
> |
| 78 |
> |
| 79 |
> |
| 80 |
> What are your thoughts? Any other proposals? |
| 81 |
|
| 82 |
Gentoo workflow should not depend on a proprietary tools like |
| 83 |
github issue tracker and github pull requests. |
| 84 |
|
| 85 |
Best regards, |
| 86 |
Andrew Savchenko |
Archives