Gentoo Archives: gentoo-project

From: Michael Everitt <m.j.everitt@×××.org>
To: gentoo-project@l.g.o
Subject: Re: [gentoo-project] call for agenda items -- council meeting 2019-04-14
Date: Wed, 03 Apr 2019 21:39:24
Message-Id: 52d3147b-7898-87dc-2d00-842a35d0f3ab@iee.org
In Reply to: Re: [gentoo-project] call for agenda items -- council meeting 2019-04-14 by Andrew Savchenko
1 On 03/04/19 19:12, Andrew Savchenko wrote:
2 > On Wed, 3 Apr 2019 17:43:15 +0300 Andrew Savchenko wrote:
3 >> On Wed, 3 Apr 2019 10:04:36 -0400 NP-Hardass wrote:
4 >>> On 4/3/19 8:43 AM, Alec Warner wrote:
5 >>>>
6 >>>> On Wed, Apr 3, 2019 at 7:31 AM NP-Hardass <NP-Hardass@g.o
7 >>>> <mailto:NP-Hardass@g.o>> wrote:
8 >>>>
9 >>>> On 3/31/19 11:20 PM, William Hubbs wrote:
10 >>>> > Hi all,
11 >>>> >
12 >>>> > two weeks from today (2019-04-14) the Gentoo Council will meet at
13 >>>> > 19:00 UTC in the #gentoo-council channel on freenode.
14 >>>> >
15 >>>> > Please reply to this message with any items you would like us to
16 >>>> put on
17 >>>> > the agenda to discuss or vote on.
18 >>>> >
19 >>>> > Thanks much,
20 >>>> >
21 >>>> > William
22 >>>> >
23 >>>>
24 >>>> I'd like the council to discuss the issue and general trend of actions
25 >>>> (particularly recent) to restrict the ability of developers to
26 >>>> contribute to Gentoo.  In my view, efforts are being made to make
27 >>>> contributions as users substantially easier, while efforts are being
28 >>>> made to make being a developer substantially harder.  The months of
29 >>>> studying, quiz taking, and interviews set a bar that should make
30 >>>> contributions from those individuals that become developers easier than
31 >>>> the average user, not more difficult.
32 >>>>
33 >>>>
34 >>>> This is a pretty vague statement, are there particular things you want
35 >>>> the council to review; or just the 'general trend'?
36 >>>> I'm not aware of any recent changes to the developer onboarding process.
37 >>>>
38 >>>> -A
39 >>>>  
40 >>>>
41 >>>>
42 >>>> --
43 >>>> NP-Hardass
44 >>>>
45 >>> Not just the onboarding, but the retention too. General trend is what
46 >>> I'm proposing should be discussed publicly during the meeting.
47 >>>
48 >>> Three points:
49 >>>
50 >>> At present time, everyone needs a "Real Name" to contribute. A user,
51 >>> with a new email address, can allege to be "Foo Bar" and contribute
52 >>> without impediment, but, as recent proposals would have it, developers
53 >>> would need to show proof of ID over video call to become part of the web
54 >>> of trust for committing. That effectively allows any user to remain
55 >>> anonymous by using a false name, obviating a huge portion of the alleged
56 >>> benefit to requiring names in the first place. So, developers can be
57 >>> held to such a high standard that they can either no longer contribute,
58 >>> while we trim eligible pool of new developers and compare that to the
59 >>> ease with which any "named" contributor on github or bugzilla can do as
60 >>> they please.
61 >>>
62 >>> We currently have a RFC, just posted two days ago, for developers to be
63 >>> regularly tested to maintain commit status. Again, if the developer
64 >>> feels like it, maybe it is easier for him/her to just become a plain old
65 >>> user and submit patches, waiting on the (as I see it, dwindling,) amount
66 >>> of active other developers ready to commit instead.
67 >> That RFC was issued on 1st April, so I assume it to be an ill joke.
68 >>
69 >>> Totally anecdotal, I've seen developers that have fairly decent QA on
70 >>> their own commits merge PRs from users without full review and
71 >>> introducing a whole host of issues because code from users isn't always
72 >>> vetted as thoroughly as ones own work. So, I'd argue, the QA standards
73 >>> of being a dev don't quite apply to you as stringently once you
74 >>> downgrade to being a user...
75 >>>
76 >>> At the end of the day, holding developers to higher standards than users
77 >>> is a given, but it shouldn't be more onerous to be a developer than to
78 >>> be a user contributing.
79 >> As you already noted, users also have to sign-off contributions with
80 >> their real names, though we have no way to verify those names, as
81 >> well as for developers actually.
82 >>
83 >> Will all due respect GLEP76 was prepared by people without much
84 >> legal expertise and creates more problems than solves. The part of
85 >> GLEP76 mandating real name signatures *must* be amended.
86 >>
87 >> Why? We have no way to verify that provided names are valid or that
88 >> provided ID's are valid. At least in my jurisdiction such
89 >> information collected can't be used for legal action or protection
90 >> without following established government-assisted verification
91 >> procedure. In other jurisdictions similar problems may and will
92 >> arise. Additional problem is personal data collection, it is
93 >> restricted or heavily regulated in many countries. One can't just
94 >> demand to show an ID via electronic means without following
95 >> complicated data protection procedures which are likely to be
96 >> incompatible between jurisdictions.
97 >>
98 >> So the real name requirement gives us no real protection from
99 >> possible cases, but creates real and serious problems by kicking
100 >> active developers and contributors from further contributions.
101 >> NP-Hardass is not the only one. I invited some gifted people with
102 >> high quality out-of-tree work to become contributors or developers,
103 >> but due to hostile attitude towards anonymous contributors they
104 >> can't join. And people want to stay anonymous for good reasons,
105 >> because they are engaged with privacy oriented development.
106 >>
107 >> We are loosing real people, real contributions and real community.
108 >> What for? For solving imaginary problems with inappropriate tools.
109 > Since the Council usually makes decisions on some specific proposals
110 > and not on vague ideas, here is my proposal on this subject: keep real
111 > name as a recommendation, not as a requirement. See a draft patch to
112 > GLEP 76 below. It is not intended to be a final wording, but it
113 > shows the idea.
114 >
115 > diff --git a/glep-0076.rst b/glep-0076.rst
116 > index 9d5aa79..b16fae7 100644
117 > --- a/glep-0076.rst
118 > +++ b/glep-0076.rst
119 > @@ -137,8 +137,9 @@ the Certificate of Origin by adding ::
120 > Signed-off-by: Name <e-mail>
121 >
122 > to the commit message as a separate line. The sign-off must contain
123 > -the committer's legal name as a natural person, i.e., the name that
124 > -would appear in a government issued document.
125 > +either the committer's legal name as a natural person, i.e., the name
126 > +that would appear in a government issued document or the pseudonym.
127 > +Usage of the legal name is recommended.
128 >
129 > The following is the current Gentoo Certificate of Origin, revision 1:
130 >
131 > @@ -242,10 +243,9 @@ to protect the Gentoo infrastructure owners and improve consistency.
132 >
133 > The copyright model is built on the DCO model used by the Linux kernel
134 > and requires all contributors to certify the legitimacy of their
135 > -contributions. This also requires that they use their real name for
136 > -signing; an anonymous certification or one under a pseudonym would not
137 > -mean anything. This policy is derived from the Linux project's policy
138 > -[#SUBMITTING-PATCHES]_.
139 > +contributions. This also requires that they use their real name
140 > +(recommended) or a pseudonym for signing. This policy is derived from the
141 > +Linux project's policy [#SUBMITTING-PATCHES]_.
142 >
143 > In the future, a second stage of this policy may use a combination of
144 > the DCO model and an FLA model [#FLA]_ as it is used by different open
145 >
146 >
147 > Best regards,
148 > Andrew Savchenko
149 I would also note, that I know several people using pseudonyms whose real
150 identity I don't, and have no wish to, know; who have documents verifying
151 their right to use said pseudonym as their legal identity. Therefore if you
152 were insistent on pursuing copyright claims, you could equally use said
153 identity to carry out such procedures. In reality, I don't see Gentoo
154 pursuing any legal cases, nor having to address any copyright claims, as I
155 have certainly seen no requests to either the Council as governing body NOR
156 trustees as the legal entity representing Gentoo Linux.
157
158 IANAL, but I certainly agree with the synopsis that the council is somewhat
159 obsessed with "... solving imaginary problems with inappropriate tools".
160
161 Let's see some Real World examples of situations that have caused the
162 council a problem (no I don't want a whole bunch more straw men made), and
163 I invite the trustees to present real world cases of enquiries they have
164 received relating to such issues.

Attachments

File name MIME type
signature.asc application/pgp-signature