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