1 |
On Thu, 27 Oct 2016 09:42:22 -0400 |
2 |
Rich Freeman <rich0@g.o> wrote: |
3 |
|
4 |
> On Thu, Oct 27, 2016 at 9:13 AM, Michał Górny <mgorny@g.o> wrote: |
5 |
> > On Thu, 27 Oct 2016 07:07:20 -0400 |
6 |
> > Rich Freeman <rich0@g.o> wrote: |
7 |
> > |
8 |
> >> |
9 |
> >> I think this reflects reality. You can submit all the patches you |
10 |
> >> want via bugzilla but it isn't like we punish developers for not |
11 |
> >> getting around to accepting them, unless they're completely inactive |
12 |
> >> Gentoo-wide. |
13 |
> > |
14 |
> > I disagree here. I dare say that Bugzilla is obligatory for all |
15 |
> > developers (they get an account there during recruitment, after all). |
16 |
> > I agree they aren't required to accept patches but if a developer |
17 |
> > outright ignores all attempts of communication, you know what needs to |
18 |
> > be done. |
19 |
> > |
20 |
> |
21 |
> Recruit more maintainers or treeclean the package if it is a blocker? |
22 |
> |
23 |
> While I don't really care for the whole passive-aggressive thing that |
24 |
> some seem to enjoy, mere inaction by a volunteer in certain areas is a |
25 |
> hard problem to deal with, because if they're making positive |
26 |
> contributions in others it is hard to demand that they make a positive |
27 |
> contribution in an area that we choose. |
28 |
> |
29 |
> I get that being met with silence is highly frustrating, and I've been |
30 |
> on the receiving end of it. Still, often the best solution isn't to |
31 |
> try to force somebody to do things our way, but to try to encourage |
32 |
> others to join in so that we have somebody to work with who is willing |
33 |
> to do it our way. |
34 |
> |
35 |
> That is of course what this GLEP is all about. |
36 |
> |
37 |
> > |
38 |
> > To be honest, after writing it all down, I started to get the feeling |
39 |
> > it isn't necessary after all. The initial idea (and what motivation was |
40 |
> > supposed to mean) was that all previous attempts failed because they |
41 |
> > either tried to be too specific, force too many style rules or just |
42 |
> > never got necessary 'global' to reach all affected parties. |
43 |
> > |
44 |
> > I'd dare say this GLEP ended up confirming 'third party contributions' |
45 |
> > are not that special, we don't need special teams to handle them or |
46 |
> > special rules to cover them. |
47 |
> > |
48 |
> > So yes, it would probably be enough to put such a simple statement |
49 |
> > somewhere. The problem is: where? ;-) GLEP seemed like a |
50 |
> > straightforward solution to make it global. |
51 |
> > |
52 |
> |
53 |
> I think that is a completely fair question. |
54 |
> |
55 |
> I wouldn't be hesitant to strongly promote a specific style, |
56 |
> especially if it isn't mandatory. Convention over configuration and |
57 |
> all that. |
58 |
> |
59 |
> As far as promotion goes, I think something on this page might help: |
60 |
> https://gentoo.org/get-involved/contribute/ |
61 |
> |
62 |
> Right now that is fairly bugzilla-centric. I think expanding it to |
63 |
> offer bugzilla as one option among many could be helpful. The current |
64 |
> page doesn't even mention gentoo-proxy-maintainers. |
65 |
> |
66 |
> I do think that this is one of the areas where hasufell's concept of |
67 |
> making the 3rd-party workflow the main workflow could have helped. |
68 |
> Right now the people with commit rights mostly do things in a way that |
69 |
> it is awkward to feed 3rd-party contributions into. |
70 |
|
71 |
You are really going off-topic, you know? If the mailing list goes |
72 |
quiet for a few days, and Gentoo people start to miss some action, we |
73 |
can start discussing alternate workflows. I really like the LLVM |
74 |
project workflow but I doubt people are ready to take in such |
75 |
a major change. |
76 |
|
77 |
> So, maybe instead of a GLEP we need something in the style of a |
78 |
> contributor and committer workflow/guide that work very tightly |
79 |
> together. Then we generate some excitement on the committer side of |
80 |
> that so that people who stick their toes in the water don't have a bad |
81 |
> experience, and then we promote it to the public. |
82 |
|
83 |
That was the original idea. However, I wasn't able to figure out who |
84 |
should be 'responsible' for it. The GLEP had the advantage that it's |
85 |
really official and Council-approved, so a random developer won't say |
86 |
'what power does team X have to say about contributions?' |
87 |
|
88 |
But then, I don't really want to pursue this further. I'll leave it for |
89 |
others to decide where to put the ideas I've put into words in that |
90 |
GLEP draft. |
91 |
|
92 |
-- |
93 |
Best regards, |
94 |
Michał Górny |
95 |
<http://dev.gentoo.org/~mgorny/> |