1 |
Hi gentoo-Devs! |
2 |
|
3 |
Im writing a few ebuilds and am trying to do it right - using |
4 |
eclass funtions and stuff. Since this is java stuff not using |
5 |
make it is not the standard "./configure;make;make install". |
6 |
This is when the following idea creeped into my mind: |
7 |
|
8 |
This a RFC: |
9 |
What do you think about a public wiki, writeable by devs, where |
10 |
eclasses can be documented in a quick-and-dirty way? |
11 |
Additionally information on best practices can be made available |
12 |
in the wiki too. |
13 |
|
14 |
Motivation: |
15 |
To better the quality on user-commited ebuilds. |
16 |
|
17 |
Rationale: |
18 |
Any doc is better than no doc. |
19 |
Nicely formatted and formulated gentoo-docs are a very good |
20 |
thing. But for the few users building ebuilds it is not that |
21 |
important to have good looking Guide-XML docs, but it is |
22 |
important to have something more than the raw eclasses-sources. |
23 |
I assume there are huge amounts of functionality in the |
24 |
eclasses, but it is really hard to find a starting point for a |
25 |
user and for devs-to-be. I |
26 |
I have seen the conplains about the quality of user-commited |
27 |
ebuilds on this list and think one of the reasons is the lack of |
28 |
docs for eclasses. In addition to the hope that users get their |
29 |
ebuild better the first time, devs can reject ebuilds with a |
30 |
link to the guidelines that where not followed. This helps in |
31 |
three ways: The user might fix it himself and he is less |
32 |
frustrated, because he knows the reasons for the rejection and |
33 |
the devs dont have to get verbose over the same issues again and |
34 |
again. A sideeffect might be that a best practices standard |
35 |
might evolve that betters the overall code quality of ebuilds |
36 |
in portage. |
37 |
|
38 |
Backwards Compability: |
39 |
No problems here. |
40 |
|
41 |
|
42 |
Now you can start flaming me. |
43 |
|
44 |
Yours, Björn |
45 |
-- |
46 |
Björn Michaelsen |
47 |
pub 1024D/C9E5A256 2003-01-21 Björn Michaelsen <bmichaelsen@×××.de> |
48 |
Key fingerprint = D649 8C78 1CB1 23CF 5CCF CA1A C1B5 BBEC C9E5 A256 |