1 |
> -----Original Message----- |
2 |
> From: gentoo-dev-admin@g.o |
3 |
> [mailto:gentoo-dev-admin@g.o] On Behalf Of Michaela |
4 |
> Susan Buesing |
5 |
> Subject: Re: [gentoo-dev] Introduction to Gentoo Development |
6 |
> Teams and Processes |
7 |
> |
8 |
> |
9 |
> Be greeted, "Sir" Perc! |
10 |
|
11 |
Thank you, apologies for the delay, I've had a hell of a week |
12 |
|
13 |
> |
14 |
> Sorry, if I don't get into too much detail, concerning your |
15 |
> ideas, but don't you think, that your suggestions are |
16 |
> completely missing the point about having an OPEN (and |
17 |
> volountary) development process? |
18 |
|
19 |
Not at all, The point I was trying to raise 9and possibly tacking my |
20 |
suggestions on to the end was a mistake) was that there is no clear |
21 |
defined development process. |
22 |
Process being the important word here. |
23 |
Firstly there is no clear documentation on the site as to how the |
24 |
distribution is split amongst the developers. |
25 |
The developer lists do show what rough areas each developer uses, |
26 |
however they are not ordered by these areas, so to find out who is |
27 |
responsible for example, for KDE, you need to look down the entire list. |
28 |
This "process" is fine where you have a small number of developers, |
29 |
however as the developer list grows this process becomes unmanageable |
30 |
and unpalatable for your new developers looking to join the |
31 |
distribution. |
32 |
Secondly, there are no clearly marked descriptions of the lists, I |
33 |
signed up for most of them, mostly those that interest me, but I soon |
34 |
discovered that the lines between newbies, users and dev lists were very |
35 |
blurry. |
36 |
|
37 |
> |
38 |
> How are people/users supposed to learn and eventually become |
39 |
> fully-fledged developers if they aren't to interact/learn |
40 |
> from those who are already there? |
41 |
|
42 |
I never suggested that the development system become closed, I would |
43 |
recommend that processes for ensureing that the development system is |
44 |
open and viewable are discussed and decided upon by the whole community. |
45 |
For example, is there a set process for someone deciding to bring a new |
46 |
application into the gentoo system? I've seen several posts on dev to |
47 |
that effect, asking for advice on whether a package is being maintained |
48 |
and if not how they go about maintaining it. |
49 |
|
50 |
> |
51 |
> I for myself would have never taken the step to apply for |
52 |
> some official developer status. The open system of openly |
53 |
> available developer documentation, mailing lists and BugZilla |
54 |
> helped me a whole lot with overcoming my doubts... |
55 |
|
56 |
The open system? So exactly what happens on gnetoo-core that we aren't |
57 |
even allowed to browse it's archives? |
58 |
If I dislike the way an ebuild sets itself up on my system how do I go |
59 |
about changing that ebuild, contacting the maintainer, and contributing |
60 |
my fixes? |
61 |
|
62 |
The points I am suggesting is that these processes need to be firmly |
63 |
defined, not set down from on high, but put forward as proposals from on |
64 |
high, discussed and agreed upon, then enforced. |
65 |
Of coruse there are different systems for deciding the development |
66 |
processes, the -core team could simply decide them and put them in |
67 |
place, but that might not be the best move, on the other hand that might |
68 |
be a good move. |
69 |
These are the thigns that need to be discussed, the processes for the |
70 |
development of the system. The current system wherevy the processes are |
71 |
vaguely known to everyone is fine for a small group of core developers |
72 |
and a slightly larger group of general developers. With less than one |
73 |
hundered people, it could be viewed that the processes are working fine. |
74 |
However these processes are not working fine because they are not |
75 |
officially mandated and recorded. |
76 |
Once a policy is created it should be open to change naturally, when I |
77 |
looked at this community and lurked on the mailing lists I immediately |
78 |
thought of a proposal -> specification -> final process model. |
79 |
In my eye, anybody could propose either a change in policy or a whole |
80 |
new policy for any area that they feel is not fully covered. |
81 |
They would get a proposal form of some sort and submit it to the |
82 |
gentoo-dev list for example, the gentoo-dev would dsicuss the proposal, |
83 |
and a web absed system would allow developers to mark a yes or no to a |
84 |
proposal, as the proposal went around the list, changes would be made to |
85 |
it, if the proposal had more yes's than no's then it would become a |
86 |
specification, which would be discussed in -core, or even gentoo-policy |
87 |
if necessary. |
88 |
|
89 |
This is only my view of a possible system, there are millions of ways of |
90 |
designing such a system, and it would be the work of the entire |
91 |
development community to build such a system and agree to work with the |
92 |
results of such a system. |
93 |
|
94 |
> |
95 |
> I also think that input from "normal" users is the best way |
96 |
> to learn, what should be improved. - And after all, what is |
97 |
> OpenSource/open development all about in the end? |
98 |
|
99 |
Yes, my suggestion of segregating developers from users was not intended |
100 |
to be an enforced segregation like -dev and -core, but for both lists to |
101 |
be open for archival reading fromt eh public, and the -dev lists to |
102 |
require you to register, an automated system could be used, further more |
103 |
I thinkt he dev list should only be postable to by subscribers. |
104 |
The users list should be watched carefully, as I'm sure it currently is, |
105 |
by all developers and -core maintainers to get such input. |
106 |
I have other ideas for such user input systems, web based user input, |
107 |
suggestion boxes and so forth but these are my ideas, and ones that I |
108 |
will propose in due time as and when I have the time to implement them, |
109 |
or feel that they are necessary and furthermore wanted or requested. |
110 |
|
111 |
> |
112 |
> Bye, Ela. |
113 |
> |
114 |
> P.S.: Sorry, if this was a bit sharp. It's only my opinion, |
115 |
> after all. :-/ |
116 |
|
117 |
Not a problem, I understand your views and it is my mistake for mixing |
118 |
my discussion of defining processes with other ideas. |
119 |
|
120 |
My main point is that from what I have seen, Gentoo Linux has no fixed, |
121 |
defined procedures for doing things, cvs access is handed out as and |
122 |
when it is needed, future developments are decided upon by a core team |
123 |
that keep their discussions private (no offence, but why is there a need |
124 |
for gentoo-core to have private archives?), ebuilds can be submitted |
125 |
with little or no Quality assurance (which I know daniel is working on, |
126 |
and trying to find a solution to), ebuilds can be submitted and if |
127 |
entered into the portage tree are then within the hour available on all |
128 |
users amchines. |
129 |
I could go on, each of these problems can and will be sorted out |
130 |
individually, but my point is that these problems are not the problems |
131 |
so to speak they are symptoms of a deeper problems and that is lack of |
132 |
team management, and lack of clear guidelines. |
133 |
|
134 |
P.s. Thank you I found the FAQ, I had seen it before but I |
135 |
mis-represented my original point, I was suggesting a development FAQ, |
136 |
nota users FAQ, again somewhere where there needs to be a finer split |
137 |
in my opinion |
138 |
|
139 |
|
140 |
(I appear to have misplaced my PGP plugin in MS Outlook, so this one |
141 |
isn't signed, I hate MS software!) |
142 |
This email was written by Sir Perc (Mr M. Spall) and should be |
143 |
accompanied by a signature for checking with PGP, available at |
144 |
http://www.pgpi.org |
145 |
My PGP Key is available with the email address sirperc@×××××.com |