1 |
> you should look at |
2 |
> the archives to see what people decided. |
3 |
|
4 |
from reading the archives and the response so far as well as the current |
5 |
documentation on the subject i conclude that the issue is still not clear |
6 |
and people make up their own stuff as they go along. |
7 |
|
8 |
the following may be a formalisation of current (best) practices: |
9 |
|
10 |
- maintainers fall into three categories. herds, gentoo developers and |
11 |
non-gentoo proxy maintainers. |
12 |
|
13 |
- a herd is defined in herds.xml. exception: no-herd. no-herd is limited |
14 |
to the situation where no suitable herd can be found. |
15 |
|
16 |
- a gentoo developer is defined in dev-rel/roll-call/userinfo.xml. |
17 |
|
18 |
- every ebuild has a herd. |
19 |
|
20 |
- a package can belong to more than one herd. |
21 |
|
22 |
- a package can be maintened by no or more parties. |
23 |
|
24 |
- a package with herd different from 'no-herd' is said to be maintained |
25 |
by the members of that herd. |
26 |
|
27 |
- all maintainers different from herds state their maintainership using |
28 |
the <maintainer> tag. the <maintainer> tag requires the <email> tag. |
29 |
|
30 |
- a package with herd 'no-herd' and no additional maintainers is said to |
31 |
be unmaintained. |
32 |
|
33 |
- a <maintainer> of maintainer-needed@g.o indicates no maintainership and |
34 |
is only allowed as the sole maintainer. meaning a single <maintainer> |
35 |
tag and a single <herd>no-herd</herd> tag. infact it is semantically |
36 |
equivalent to a single <herd>no-herd</herd> tag and no additional |
37 |
maintainers. |
38 |
|
39 |
- a package that is proxy maintained needs an additional gentoo |
40 |
association in form of a maintaining herd or gentoo developer. |
41 |
maintainer-needed@g.o may be such an association, but only if the |
42 |
original one disappeared. |
43 |
|
44 |
optionally one may want to include, although personally i prefer to state |
45 |
it explicitly: |
46 |
|
47 |
- a missing or empty <herd> tag is equivalent to <herd>no-herd</herd> |
48 |
|
49 |
open questions: |
50 |
|
51 |
- what does it mean when the package is maintained by a herd and an |
52 |
additional maintainer? how does one determine the order in which to |
53 |
contact multiple maintainers? |
54 |
|
55 |
- are there situations in which we specify a <herd> other than no-herd |
56 |
but don't want its members to act as maintainers? |
57 |
|
58 |
... |
59 |
|
60 |
what are your current best practices regarding metadata? |
61 |
regards |
62 |
Thilo |