1 |
>| Is there any possibility that easier low quality contribution makes |
2 |
>| the high quality contributions easier? |
3 |
> |
4 |
>Only to the extent that they get me to write better documentation :) |
5 |
> |
6 |
>| Look at wikipedia - it's amazing that such high quality work (in |
7 |
>| general) can come from lightly peer review material with low barriers |
8 |
>| to entry. |
9 |
>| |
10 |
>| Clearly not an appropriate model here, but I can't help wondering if |
11 |
>| there is not another way... |
12 |
> |
13 |
>Well... Sometimes maintainer-wanted ebuilds are worked upon by multiple |
14 |
>people. It happens, but not very often. |
15 |
> |
16 |
> |
17 |
|
18 |
I was pondering this last night. |
19 |
|
20 |
Whilst there is clearly no substitute for a high quality standard for |
21 |
"x86", etc, it seems to me that we are missing a trick with all the |
22 |
"maintainer wanted" ebuilds which tend to be scattered around the web. |
23 |
|
24 |
It seems to me that perhaps it would be useful to have a centralised |
25 |
development area where stuff can "gestate" before making it into the |
26 |
testing pool that we have today. It could be argued that this exists |
27 |
and is called bugzilla, but I wonder if we can do better? |
28 |
|
29 |
What about adding another layer (or two) to the flags so that |
30 |
development ebuilds can be developed centrally to gentoo and hence |
31 |
available in portage, but lowering the barrier to entry. At the |
32 |
simplest this could be used to allow a non core developer to bump an |
33 |
ebuild to a new version in response to some release. It goes into the |
34 |
"highly unstable" section which shouldn't be seen by any normal person, |
35 |
yet at the same time makes it available to the kiddies who like to test |
36 |
the latest and greatest. |
37 |
|
38 |
Now, the follow on to this idea is as follows: It seems to me to be a |
39 |
little arbitrary when something goes stable and I find myself with a |
40 |
number of "~" flags set on an otherwise fairly stable system (I dare say |
41 |
you have a different opinion, but remember I am looking from the outside |
42 |
in). |
43 |
|
44 |
Now, at one point in the past there was a gentoo package which phoned |
45 |
home and reported which version of every package you were using. Could |
46 |
these statistics not be used to help direct development time to the most |
47 |
useful areas? I'm thinking along the lines of noticing that 90% of the |
48 |
userbase is running a version of xmltv which is 5 versions newer than |
49 |
the stable one, hence it's probably fairly stable, and in need up being |
50 |
marked as stable... |
51 |
|
52 |
These statistics could also be used as a first line quality check for |
53 |
any ebuilds in the proposed "development" ebuild area. So for example, |
54 |
if there is a hard-core of users using my "pmwiki" ebuild (which is |
55 |
currently marked as "maintainer wanted"), then this is a clue that it |
56 |
must be fairly stable and popular and worth including (since it will |
57 |
probably require minimal effort). |
58 |
|
59 |
It seems like this would go some way towards easing the "easy |
60 |
development" bits and giving everyone more time to work on the important |
61 |
stuff, whilst also making use of the distributed testing effort of some |
62 |
of the more adventurous users... |
63 |
|
64 |
Workable? |
65 |
|
66 |
Ed W |
67 |
-- |
68 |
gentoo-dev@g.o mailing list |