Gentoo Archives: gentoo-project

From: Tom Wijsman <TomWij@g.o>
To: slong@××××××××××××××××××.uk
Cc: gentoo-project@l.g.o
Subject: Re: [gentoo-project] Re: Daunting developer process? (was Re: Call for agenda items - Council meeting) 2013-09-10
Date: Wed, 18 Sep 2013 14:00:52
Message-Id: 20130918155539.7d10ffc9@TOMWIJ-GENTOO
In Reply to: [gentoo-project] Re: Daunting developer process? (was Re: Call for agenda items - Council meeting) 2013-09-10 by "Steven J. Long"
1 On Wed, 18 Sep 2013 13:18:28 +0100
2 "Steven J. Long" <slong@××××××××××××××××××.uk> wrote:
3
4 > On Wed, Sep 18, Sven Vermeulen wrote:
5 > > Using a different approach to gain more developers might have more
6 > > impact than you imagine on the quality of the distribution as well
7 > > as the progress it makes. If the distribution would be 12
8 > > developers, it wouldn't be all that hard to make a good roadmap and
9 > > focus areas. Twelve people can easily decide amongst each other
10 > > what to do. But 200+ developers is a different ballgame (hence the
11 > > need for "bureaucratic" things like the Gentoo Council) where
12 > > decisions need to be weighted and where every individual can
13 > > contribute (or block) to the progress of the distribution.
14 > >
15 > > Imagine what would happen if we had 500+ developers.
16 >
17 > Thanks you for a wonderfully succinct explanation of the damage that
18 > would be done if Gentoo developer status were awarded to people who
19 > did not nderstand how to develop the end-product, eg: out of
20 > deference to technical knowledge in other domains.
21
22 Yes, the process that is in place is there to avoid people from rushing
23 in only to be met with an unhappy community because they made some
24 unintended change that doesn't meet earlier policy or consensus that
25 is in place to avoid such damaging changes in the first place; we've
26 had people ask for straight CVS access in the past (and even locked
27 forum discussions) for just applying one ore another fix, but you guess
28 how making a commit without knowing the context can lead to disasters.
29
30 > Can I ask that you paste the whole text of your response into the
31 > Gentoo docs site somewhere? This comes up so often, on the forums and
32 > on IRC, it would help to have it where people will see it. Personally
33 > I'd paste it at the top of the devmanual front-page, so giving
34 > someone the link to that also ensures they are looking at it. Your
35 > call, ofc.
36
37 At verbatim at the top of the devmanual doesn't really look neat out of
38 the context of this discussion, but I guess you didn't mean it to be
39 exact; looking at what we already have in place I see this in the
40 Developer Handbook [1]:
41
42 The aim of this handbook is to outline Gentoo development policies,
43 and make you, the developer, informed of policies, standards and
44 procedures which Gentoo considers to be core values of our
45 development system.
46
47 And people are warned up front in the Ebuild policy [2]:
48
49 Be cautious about what you commit. Remember that your commits can
50 potentially harm thousands of users. If your commits cause any
51 breakage in the tree, they must be fixed in a timely fashion.
52
53 And in the Etiquette policy [3]:
54
55 That doesn't mean that we expect you to follow this guide to the
56 bullet point; nor do we expect you even agree with it - we do
57 expect, however that all developers maintain reasonable standards
58 of behaviour with our community - whether to other developers or
59 users. However, you may be subject to sanctions or a suspension if
60 a reasonable standard is not met.
61
62 But I agree with you that there doesn't seem to be the "why" part to
63 why people should read the Developer Handbook; but then one might
64 wonder if such "why" part needs to be there in the first place, because
65 if people aren't interested in reading (and thus following) any
66 policies, then how can we expect them to not harm the community?
67
68 If they question it, then I feel like it is fine to inform them why we
69 expect them to follow the process; but telling them up front that not
70 reading it causes harm feels like a negative connotation, which could
71 scare people from contributing in the first place.
72
73 For that reason, they actually do not detail the process too much; we
74 want people to join with a positive mood that they learned something,
75 not with "the process is lengthy and boring" or "wow, finally, meh".
76
77 Looking back at it, most of us can be glad the process is in place.
78
79 As for the Development Manual; I feel like we could refer [4] to the
80 Developer Handbook so people that don't know about it could find it,
81 but I don't think Developer Handbook information itself belongs there.
82
83 [1]: Developer Handbook - Introduction
84 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=1
85
86 [2]: Developer Handbook - Ebuild policy
87 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=1
88
89 [3]: Developer Handbook - Etiquette policy
90 http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=2
91
92 [4]: GitHub Pull Request - Add a reference to Gentoo Developer Handbook
93 https://github.com/gentoo/devmanual.gentoo.org/pull/9
94
95 --
96 With kind regards,
97
98 Tom Wijsman (TomWij)
99 Gentoo Developer
100
101 E-mail address : TomWij@g.o
102 GPG Public Key : 6D34E57D
103 GPG Fingerprint : C165 AF18 AB4C 400B C3D2 ABF0 95B2 1FCD 6D34 E57D

Attachments

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