Alistair Bush wrote:
>
>
> Tiziano Müller wrote:
>> Current state: "Deferred"
>> Wanted state: "Accepted/Implemented" (at least by me)
>>
>> Open questions from last discussion (March 2006):
>> - Is it possible/should it be possible to have more than one <maintainer>
>> entry?
>
> Yes
>
>> - Is recording an upstream-status (active/inactive) a good idea?
> Maybe, leaning to No.
>
> What about packages that have multiple slots, e.g php-4, php-5? one
> slot could be inactive the other not, does that make upstream active?
Well, upstream for php-4 is not inactive (it still exists but answers with
a "won't fix" if you report a bug for php-4).
But there might be a case that there are two maintainers of different
branches of a software. Doesn't seem like a common case, does it?
Nevertheless: ideas?
>
>> Possibilities:
>> An element: <status>{active/inactive}</status>
>
> Status of what? seeing you have proposed a upstream-status and a
> maintainer status. what else is there left to status :P
There will be a <maintainer> tag within the <upstream></upstream>, not the
same as our already existing <maintainer>
But the question I tried to express (probably not clear enough) is:
Should (if at all) the status being tracked for <upstream> or for
<maintainer> (within upstream).
As an example "dev-libs/xmlwrapp": The original maintainer is inactive, but
there is a new one who took the package to sourceforge and it's not a fork
since the original maintainer agreed up on this. Should such a case be
tracked at all?
>
>> An attribute: <maintainer status="{active/inactive}">...
> No. As i'm pretty sure that every inactive maintainer won't go around
> updating their packages metadata.xml
Not talking about the existing <maintainer> tag, sorry.
>
>> - Is an additional <doc> element needed to link to upstream docs
> Interesting. what about the situation where upstream documentation sucks
> but there is a "better" resource provided by a third party, could we
> link to that? e.g. http://tldp.org for bash is an excellent resource
> Multiple doc links?
> <docs><official-doc/><official-doc/><doc/><doc/></docs> could provide
> that. Only concern I see is that this could relate to an endorsement of
> thirdparty websites, which may change negatively ( porn on tldp.org ) or
> my just become outdated.
>
> Actually without the multiple official/unofficial doc tags I would have
> to say No. as 99% of the time it would just be "${HOMEPAGE}/doc" or
> there would be a big fat link from the homepage and therefore would be
> of no real benefit.
Hmm, good point. Maybe we have to narrow the specification for <doc> to only
point to package maintainer info?
Since it can also change between versions, slots, etc...
--
[email protected] mailing list
