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 <gentoo-dev+bounces-29040-garchives=archives.gentoo.org@lists.gentoo.org>)
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 <gentoo-dev@lists.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>; 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 <gentoo-dev@lists.gentoo.org>;
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 <gentoo-dev@gentoo.org>; 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 <gentoo-dev@gentoo.org>; 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 <gentoo-dev@gentoo.org>; 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?= <dev-zero@gentoo.org>
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: <fmt444$87g$1@ger.gmane.org>
References: <fmssmd$jat$1@ger.gmane.org> <47920F76.3090100@gentoo.org>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
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 <news@ger.gmane.org>
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 <maintain=
er>
>> 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: <status>{active/inactive}</status>
>=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 <maintainer> tag within the <upstream></upstream>, not th=
e
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, 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: <maintainer status=3D"{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.
>=20
>> - Is an additional <doc> 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?
> <docs><official-doc/><official-doc/><doc/><doc/></docs> 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 <doc> 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