From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1JGFP4-000485-Pz for garchives@archives.gentoo.org; Sat, 19 Jan 2008 15:14:39 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 06551E075F; Sat, 19 Jan 2008 15:14:37 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id B1968E075F for ; Sat, 19 Jan 2008 15:14:36 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 43F69656E5 for ; Sat, 19 Jan 2008 15:14:36 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 required=5.5 tests=[AWL=0.609, BAYES_00=-2.599] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iS01tyJQ-Leo for ; Sat, 19 Jan 2008 15:14:30 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 249006525F for ; Sat, 19 Jan 2008 15:14:28 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1JGFOn-0004Qy-LM for gentoo-dev@gentoo.org; Sat, 19 Jan 2008 15:14:23 +0000 Received: from gw.ptr-80-238-132-74.customer.ch.netstream.com ([80.238.132.74]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Jan 2008 15:14:21 +0000 Received: from dev-zero by gw.ptr-80-238-132-74.customer.ch.netstream.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 19 Jan 2008 15:14:21 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Tiziano =?ISO-8859-1?Q?M=FCller?= Subject: [gentoo-dev] Re: GLEP 46: Allow upstream tags in metadata.xml Date: Sat, 19 Jan 2008 16:13:51 +0100 Organization: Gentoo Message-ID: References: <47920F76.3090100@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: gw.ptr-80-238-132-74.customer.ch.netstream.com User-Agent: KNode/0.10.5 Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: dcb4350d-dacd-408c-9df9-a2acd24b1c46 X-Archives-Hash: f7f9a1cd0e75ba1fc73e6ba04ff4fd40 Alistair Bush wrote: >=20 >=20 > Tiziano M=FCller wrote: >> Current state: "Deferred" >> Wanted state: "Accepted/Implemented" (at least by me) >>=20 >> Open questions from last discussion (March 2006): >> - Is it possible/should it be possible to have more than one >> entry? >=20 > Yes >=20 >> - Is recording an upstream-status (active/inactive) a good idea? > Maybe, leaning to No. >=20 > 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 wit= h 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? >=20 >> Possibilities: >> An element: {active/inactive} >=20 > 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 tag within the , not th= e same as our already existing But the question I tried to express (probably not clear enough) is: Should (if at all) the status being tracked for or for (within upstream). As an example "dev-libs/xmlwrapp": The original maintainer is inactive, b= ut there is a new one who took the package to sourceforge and it's not a for= k since the original maintainer agreed up on this. Should such a case be tracked at all? >=20 >> An attribute: ... > No. As i'm pretty sure that every inactive maintainer won't go around > updating their packages metadata.xml Not talking about the existing tag, sorry. >=20 >> - Is an additional element needed to link to upstream docs > Interesting. what about the situation where upstream documentation suck= s > 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? > could provide > that. Only concern I see is that this could relate to an endorsement o= f > thirdparty websites, which may change negatively ( porn on tldp.org ) o= r > my just become outdated. >=20 > 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 to o= nly point to package maintainer info? Since it can also change between versions, slots, etc... --=20 gentoo-dev@lists.gentoo.org mailing list