1 |
On 6/7/20 8:24 PM, Ralph Seichter wrote: |
2 |
> * Haelwenn Monnier: |
3 |
> |
4 |
>> It's not to jump the queue, in fact I get about the same lag in my |
5 |
>> experience between GitHub PRs and using email. But it's much less |
6 |
>> predictable. |
7 |
> I don't understand the second sentence; what X is less predictable than |
8 |
> what Y, and why? As for the first sentence, I have my doubts, because |
9 |
> with less than 1% of contributors posting email patches, the ones that |
10 |
> do are very much "in your face" about it. |
11 |
> |
12 |
>> I'd rather avoid GitHub completely, I do use it from time to time but |
13 |
>> because I have to. |
14 |
> I respect your right to dislike GitHub, but this is not about you alone |
15 |
> but about having automated CI checks and a unified means of letting the |
16 |
> proxy-maint members doing their volunteer job, in their own time, in a |
17 |
> comfortable way. Disclaimer: I do not speak for the P-M team, nor do I |
18 |
> claim to. |
19 |
> |
20 |
> Another important aspect is that, by using GitHub, you allow only the |
21 |
> interested parties to subscribe to your pull requests (and I assume very |
22 |
> few would be interested). Posting patches here is, again, "in your |
23 |
> face", because rather than individually opting in on GitHub PRs, you are |
24 |
> forcing people to opt out every time you post a patch. I consider this |
25 |
> both impolite and annoying. |
26 |
> |
27 |
>> And while sending via GitHub sometimes works I also got at least one |
28 |
>> PR later reverted because it didn't get a proper ACK from the |
29 |
>> maintainers, if I have to also ping them through email, why not just |
30 |
>> send the patch via email? |
31 |
> Because one of your PRs being met with a hiccup does not remotely |
32 |
> justify skipping the agreed-upon, preferred method of contribution |
33 |
> altogether. |
34 |
> |
35 |
> There are OSS projects that use email-based patches successfully and |
36 |
> consistently, like "Notmuch" does. Howevery, Notmuch has the necessary |
37 |
> infrastructure to deal with these patches, and a culture of reviewing |
38 |
> these patches on the mailing list. Gentoo does not operate this way. |
39 |
> |
40 |
>> There is also the problem of having to sync your repo to GitHub, if I |
41 |
>> forget to push gentoo's master to my fork I end up having to send all |
42 |
>> the past history manually, and I discovered this one quite later on. |
43 |
> You must be joking, right? Synchronising two Git remotes is no more |
44 |
> complicated than using "git send-email", and even if it was, learning to |
45 |
> use Git is mandatory. I remember nearly making a mess of my very first |
46 |
> pull request because of a Git-related mistake, which other people |
47 |
> obviously noticed. I assure you that I never made that mistake again, |
48 |
> and I am confident you can manage as well. |
49 |
> |
50 |
>> Finally, I don't have this issue but github isn't available to |
51 |
>> everyone depending on where they live, and often a VPN isn't an |
52 |
>> option there, so another option needs to exists. |
53 |
> As I wrote right off the bat: I know patches *may* be posted here. That |
54 |
> does not imply they should, especially if the author, like yourself, |
55 |
> admittedly has the ability to use GitHub instead, which is clearly the |
56 |
> preferred method of contributing. If GitHub is an option, posting |
57 |
> patches here is both unnecessary and rude, in my opinion. |
58 |
> |
59 |
> -Ralph |
60 |
|
61 |
Hey, |
62 |
|
63 |
there are some bits in this message where the tone comes out a bit |
64 |
hostile. I'd hope we can continue this discussion in a civil manner. |
65 |
|
66 |
There were some interesting points already and I can see the bandwith be |
67 |
a problem for some. |
68 |
|
69 |
In the end, we are *all* trying to make Gentoo better, right? I am |
70 |
thankful of every contribution, and this mailing list is low traffic at |
71 |
the moment. If Github is not an option, please don't let that stop you |
72 |
from contributing. You can of course send git-format patches directly to |
73 |
proxy-maint@g.o, too. |
74 |
|
75 |
But I'm still interested about the discussion _why_ Github doesn't work |
76 |
for everyone. We can maybe find some new ideas or new ways, when we are |
77 |
aware of all the problems. |
78 |
|
79 |
-- juippis |