1 |
I've been thinking about the problem stated a few days ago about portage |
2 |
maintenance... first of all, I'm not on the developer list, so I don'tknow if |
3 |
many of the assumptions I'm making here are right or wrong, so a big "correct |
4 |
me if I'm wrong" must be assumed everywhere... well, here it goes... |
5 |
|
6 |
THE PROBLEM |
7 |
|
8 |
Portage is slowly getting out of date. Some facts: portage has 7600 packages, |
9 |
and more than 80.000 files, but only 200 devs. This is clearly insufficient |
10 |
to maintain such a system. |
11 |
|
12 |
DEVS RESPONSABILITIES |
13 |
|
14 |
The Gentoo devs have the following responsabilities (correct me if I'm wrong): |
15 |
- Mantain a structure giving support for Gentoo |
16 |
- Develop portage (the core of Gentoo) |
17 |
- Enhance the current platform with the creation of new projects specific to |
18 |
Gentoo |
19 |
- Create and mantain ebuilds |
20 |
- Create and mantain Gentoo specific patches for those ebuilds |
21 |
- Resolve bugs created at bugs.gentoo.org |
22 |
|
23 |
MY RANDOM THOUGHTS |
24 |
|
25 |
A. REGISTERED USERS / TESTERS |
26 |
Well, first of all, open source software is all about participation, but how |
27 |
many Gentoo users would want to become a developer? Probably few. We all have |
28 |
college, works, families, hobbies,... and Gentoo would be another thing |
29 |
stealing our precious time, so how to get more developers? Does Gentoo really |
30 |
need more developers? |
31 |
|
32 |
Let's see... from my point of view, there are "core" responsabilities and |
33 |
"secondary" responsabilities. I mean that the real heart of Gentoo is |
34 |
basically portage, so I think core developers should concentrate on further |
35 |
developing and enhancing the Gentoo base, while leaving the "mundane" tasks |
36 |
of creating ebuilds and resolving bugs to other people, or maybe a second |
37 |
level of developers. Anyway we still have the problem of few developers |
38 |
dealing with a lot of ebuilds. |
39 |
|
40 |
I think (again correct me if I'm wrong) that a great part of the ebuild |
41 |
creation and maintenance task consist of testing the ebuilds, so they install |
42 |
the software properly, and there are no problems once that software is |
43 |
installed. Then that ebuild enters the unstable branch, and if there are no |
44 |
further problems, the ebuild become stable... and here is where I think the |
45 |
system may be greatly improved: |
46 |
|
47 |
Let's say Gentoo creates new posts: registered users and/or registered |
48 |
testers. Ok, maybe there are few out there wanting to become a developer, but |
49 |
there are tons of users out there continously installing and testing Gentoo. |
50 |
Why don't take advantage of that? The developer task may take a lot of time, |
51 |
and may be not rewarded, but testing new software is something that people |
52 |
uses to do while they're studying, working, or even playing at home. Let's |
53 |
make them take a step further: become a registered user or tester that |
54 |
reports directly to Gentoo their success or failure, instead of just writing |
55 |
to some list saying they have a problem, or they've been successful while |
56 |
installing and using an ebuild. |
57 |
|
58 |
I would do this per package. I mean a registered user/tester would be |
59 |
associated with a set of packages she uses on a daily basis. Testers would |
60 |
have an associated rating of reliability (I don't know if this is the best |
61 |
word for this) and would be notified whenever a new version of the package |
62 |
comes out. So I see the process somewhat like this: |
63 |
|
64 |
1. Somebody (dev or not) writes a new ebuild |
65 |
2. If not submitted by a dev, a dev checks the ebuild for form defects (bad |
66 |
CVS tags, USE flags unproperly used,...) and admits or rejects the ebuild |
67 |
3. Registered testers are notified of it |
68 |
4. During testing period, registered testers report success or failure, |
69 |
weighed up based on their reliability rating. The ebuild may change, |
70 |
resetting the testing period. |
71 |
5. Once the testing period has finished, if the average of success reports |
72 |
weighed up with reliability ratings is greater that a threshold, accept the |
73 |
ebuild and put it in the unstable branch, maybe repeating the process with |
74 |
registered users. |
75 |
|
76 |
I guess this is what is done right now at bugzilla in an informal way, but I |
77 |
think that formalizing this process would have a few benefits: |
78 |
|
79 |
1. Right now (at least in my case) people know of new ebuilds in bugzilla when |
80 |
they actively search for a package in bugzilla. The automatic notify process |
81 |
would greatly increase the testing of new ebuilds just created in bugzilla, |
82 |
instead of limiting this testing to people that just has found the bug |
83 |
2. A tester has a much lower responsability and time dedication than a |
84 |
developer, so people in their daily jobs could develop this role |
85 |
3. The testing work of a developer could be delegated on these testers, and in |
86 |
turn they could use their time for more important things, just having the |
87 |
responsability of reviewing reports and taking a decission based on that. |
88 |
|
89 |
One of these testers could eventually become an ebuild submitter, or even a |
90 |
package mantainer. |
91 |
|
92 |
B. AUTOMATIC INFORMATION RETRIEVAL |
93 |
Another thing that I think could be interesting is some form of automated |
94 |
sending of information about installed packages in test/production |
95 |
environments. Registered users / testers could install a tool in their |
96 |
systems that would send information to some kind of server about their |
97 |
platform, gcc/glibc versions and options, use flags, installed packages, ... |
98 |
That information would then be used by some data mining techniques to find |
99 |
information about bugs, taking into account reports from the tester, so the |
100 |
system could relate success/failure reports with the state of the system in a |
101 |
particular moment. Maybe even this tool could also be used to send the |
102 |
reports, so the information is included in it. |
103 |
|
104 |
|
105 |
Well, that's all by now, best regards |
106 |
Jose |