1 |
Alistair Bush wrote: |
2 |
|
3 |
> |
4 |
> |
5 |
> Tiziano Müller wrote: |
6 |
>> Current state: "Deferred" |
7 |
>> Wanted state: "Accepted/Implemented" (at least by me) |
8 |
>> |
9 |
>> Open questions from last discussion (March 2006): |
10 |
>> - Is it possible/should it be possible to have more than one <maintainer> |
11 |
>> entry? |
12 |
> |
13 |
> Yes |
14 |
> |
15 |
>> - Is recording an upstream-status (active/inactive) a good idea? |
16 |
> Maybe, leaning to No. |
17 |
> |
18 |
> What about packages that have multiple slots, e.g php-4, php-5? one |
19 |
> slot could be inactive the other not, does that make upstream active? |
20 |
Well, upstream for php-4 is not inactive (it still exists but answers with |
21 |
a "won't fix" if you report a bug for php-4). |
22 |
|
23 |
But there might be a case that there are two maintainers of different |
24 |
branches of a software. Doesn't seem like a common case, does it? |
25 |
Nevertheless: ideas? |
26 |
|
27 |
> |
28 |
>> Possibilities: |
29 |
>> An element: <status>{active/inactive}</status> |
30 |
> |
31 |
> Status of what? seeing you have proposed a upstream-status and a |
32 |
> maintainer status. what else is there left to status :P |
33 |
There will be a <maintainer> tag within the <upstream></upstream>, not the |
34 |
same as our already existing <maintainer> |
35 |
|
36 |
But the question I tried to express (probably not clear enough) is: |
37 |
Should (if at all) the status being tracked for <upstream> or for |
38 |
<maintainer> (within upstream). |
39 |
|
40 |
As an example "dev-libs/xmlwrapp": The original maintainer is inactive, but |
41 |
there is a new one who took the package to sourceforge and it's not a fork |
42 |
since the original maintainer agreed up on this. Should such a case be |
43 |
tracked at all? |
44 |
|
45 |
> |
46 |
>> An attribute: <maintainer status="{active/inactive}">... |
47 |
> No. As i'm pretty sure that every inactive maintainer won't go around |
48 |
> updating their packages metadata.xml |
49 |
Not talking about the existing <maintainer> tag, sorry. |
50 |
|
51 |
> |
52 |
>> - Is an additional <doc> element needed to link to upstream docs |
53 |
> Interesting. what about the situation where upstream documentation sucks |
54 |
> but there is a "better" resource provided by a third party, could we |
55 |
> link to that? e.g. http://tldp.org for bash is an excellent resource |
56 |
> Multiple doc links? |
57 |
> <docs><official-doc/><official-doc/><doc/><doc/></docs> could provide |
58 |
> that. Only concern I see is that this could relate to an endorsement of |
59 |
> thirdparty websites, which may change negatively ( porn on tldp.org ) or |
60 |
> my just become outdated. |
61 |
> |
62 |
> Actually without the multiple official/unofficial doc tags I would have |
63 |
> to say No. as 99% of the time it would just be "${HOMEPAGE}/doc" or |
64 |
> there would be a big fat link from the homepage and therefore would be |
65 |
> of no real benefit. |
66 |
|
67 |
Hmm, good point. Maybe we have to narrow the specification for <doc> to only |
68 |
point to package maintainer info? |
69 |
Since it can also change between versions, slots, etc... |
70 |
|
71 |
|
72 |
|
73 |
-- |
74 |
gentoo-dev@l.g.o mailing list |