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... -- gentoo-dev@lists.gentoo.org mailing list