1 |
On Sat, 6 Aug 2016 19:28:19 +0000 |
2 |
Peter Stuge <peter@×××××.se> wrote: |
3 |
|
4 |
> Michał Górny wrote: |
5 |
> > Or file a pull request @ https://github.com/gentoo/gentoo/pulls. |
6 |
> > That's the most convenient solution for most of proxy-maint team |
7 |
> > members. |
8 |
> |
9 |
> How can I help improve that problematic situation? |
10 |
> |
11 |
> It's not cool to gravitate the project towards GitHub Inc. |
12 |
|
13 |
I kinda think this missed the point. ( Though I did entirely expect a |
14 |
complaint when he suggested it ) |
15 |
|
16 |
One avenue for contribution without Github: Patches by bugzilla, was |
17 |
stated. |
18 |
|
19 |
That will work, and is not restricting anyones freedom. It may however, |
20 |
restrict convenience. But not freedom. |
21 |
|
22 |
As far as I'm concerned, the statement about Github was a "oh, yeah, |
23 |
and if you want, Github works too, so if you find that more convenient, |
24 |
so do we, go right ahead, but you ain't gotta". |
25 |
|
26 |
Everyone is free to, and encouraged to, create better solutions. |
27 |
|
28 |
But there's no force to use Github. |
29 |
|
30 |
If Github dies tomorrow, Gentoo will not drop dead. The convenience |
31 |
will be lost, but people will still be completely able to send queues |
32 |
of patches via bugzilla, or email, in the event that web browsers all |
33 |
spontaneously die and cease to be free by some dark voodoo magic. |
34 |
|
35 |
`git format-patch` is after all optimised for that latter case somewhat. |
36 |
|
37 |
Maybe we should look into an Email Based submission service, create a |
38 |
gentoo mailing list exclusively for 3rd party (proxy-maint) mail patch |
39 |
queues, optimised for receiving and vetting patch sequences. |
40 |
|
41 |
You don't need some fancy Java wank for that. |
42 |
|
43 |
Then all we'd need is some alternative implementation of |
44 |
dev-perl/Gentoo-App-Pram that can read a local mbox, and select |
45 |
emails/email threads containing patch series, apply them, push them, |
46 |
and then auto-reply to the email with a confirmation. |
47 |
|
48 |
And then people could continue to use Github for their |
49 |
easy-fast-non-free-workflow, and they could use some email submission |
50 |
thing for the slightly-less-easy-but-free-as-hell workflow. |
51 |
|
52 |
And for extra fun, we could support non-patch-queue emails that |
53 |
contained references to public arbitrary git repositories and |
54 |
automatically configured itself to pick a patch series from it, like |
55 |
this example [1]: |
56 |
|
57 |
1: https://groups.google.com/forum/#!topic/linux.kernel/w957vpu3PPU |
58 |
|
59 |
I mean, What do the Linux Kernel use? It would be a shame if they were |
60 |
happening to use the email based workflow like I suggested([2,3,4]), and |
61 |
if only there was a Gentoo Staffer who knew how Linux Contributions |
62 |
worked and had documented it (sarcasm: [5]) |
63 |
|
64 |
2: https://groups.google.com/forum/#!topic/linux.kernel/w957vpu3PPU |
65 |
3: https://news.ycombinator.com/item?id=3960876 |
66 |
4: https://github.com/torvalds/linux/pull/17#issuecomment-5663780 |
67 |
5: |
68 |
https://github.com/gregkh/kernel-tutorial/blob/master/walkthrough#L47-L52 |