1 |
> Isn't the solution to have 3 levels: 'testing', |
2 |
> 'probation' & 'stable' ? |
3 |
> 'Testing' would be literally that, asking for |
4 |
> feedback from users; |
5 |
> 'probation' wb already tested for a defined period |
6 |
> -- say 30 days -- |
7 |
|
8 |
How about a crazier idea: |
9 |
|
10 |
Each package has a stability rating from 0-99 per |
11 |
architecture. |
12 |
0 means totally untested/unstable and 99 means rock |
13 |
solid/no bugs. (0-33~unstable, 34-66~testing, |
14 |
67-99~stable) |
15 |
Each new package starts at 50. Whenever a user uses |
16 |
the package, he can then vote on it by giving +1 or -1 |
17 |
(on the website or through portage). As a package |
18 |
gains rating points, more and more users would be |
19 |
inclined to use it. A user could set the minimum |
20 |
stability rating that he wanted for all packages or on |
21 |
a per package basis. |
22 |
After the user does an emerge update, the system would |
23 |
check if an installed package is above the users |
24 |
minimum. If not, the system informs the user of the |
25 |
drop and asks if he wants the package to be removed or |
26 |
not. |
27 |
|
28 |
Only the maintainer would be able to actually modify |
29 |
the package itself. Of course, big status changes |
30 |
would happen soon after a maintainer modifies a |
31 |
package. |
32 |
|
33 |
Questions to think about: |
34 |
1) Should modifications reset the status of a package |
35 |
to 50? |
36 |
2) Should a plus/minus vote forward propogate to the |
37 |
packages that depend on it? Eg. if kdelibs gets a -1 |
38 |
vote, should amarok get a -1 vote too? |
39 |
3) Should the votes backpropagate instead? |
40 |
|
41 |
Cheers, |
42 |
Ben |
43 |
|
44 |
"he who writes the code gets to choose his license, and nobody else gets to complain" - Linus Torvale |
45 |
In my honest option, it should read - "he who writes the code gets to choose his license, and everybody else complains." |
46 |
|
47 |
|
48 |
|
49 |
|
50 |
-- |
51 |
gentoo-user@g.o mailing list |