From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from palladium.cryos.net (palladium.cryos.net [80.68.90.219]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j58GGsAg020497 for ; Wed, 8 Jun 2005 16:16:54 GMT Received: from localhost (localhost [127.0.0.1]) by palladium.cryos.net (Postfix) with ESMTP id CD66E5D94D for ; Wed, 8 Jun 2005 17:37:56 +0100 (BST) Received: from palladium.cryos.net ([127.0.0.1]) by localhost (palladium [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 27769-02 for ; Wed, 8 Jun 2005 17:37:54 +0100 (BST) Received: from linux.cryos.net (linux.cryos.net [217.155.144.218]) (using SSLv3 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) by palladium.cryos.net (Postfix) with ESMTP id 275E05D943 for ; Wed, 8 Jun 2005 17:37:54 +0100 (BST) From: "Marcus D. Hanwell" Organization: Gentoo To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] ekeyword and ordering Date: Wed, 8 Jun 2005 17:18:41 +0100 User-Agent: KMail/1.8.1 References: <20050606222623.GI9084@kaf.zko.hp.com> <42A7111B.5040306@gentoo.org> In-Reply-To: <42A7111B.5040306@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1479401.qZ0IvdqgVi"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <200506081718.45869.cryos@gentoo.org> X-Virus-Scanned: by amavisd-new at palladium.cryos.net X-Archives-Salt: 4e7f0d2f-b59b-4a83-8b6b-89d2cd4eba6a X-Archives-Hash: c779e1b2fc292c6451a21bdd13797865 --nextPart1479401.qZ0IvdqgVi Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 08 June 2005 16:39, Joseph Jezak wrote: > > Agreed, the PPC team is very good at arbitrarily marking things stable > > whenever they feel like it, and often times before the maintainer does. > > This is not usually our policy. However, because we moved GCC-3.4 to > stable before many arches, there were a number of packages that needed > to be marked stable for PPC in order for the stable version to even > compile. What should we have done in this case then? > If memory serves this is where amd64 had issues, we stabilised GCC 3.4 firs= t I=20 believe as it works much better than GCC 3.3, and so many apps needed=20 patching/unstable versions. Some maintainers were not happy about this.=20 Didn't happen to me as I became a dev after there were some issues raised,= =20 and I have always try to contact the maintainer to discuss it first in the= =20 rare circumstances where it is needed. It would probably be helpful to have a ChangeLog entry saying stabilised pp= c=20 to fix GCC 3.4 compile problem or words to that effect, but I would expect= =20 that most apps have been fixed by us for our stable tree. I did think it ha= d=20 been decided that the maintainer should at least be contacted before=20 stabilising before him/her. =2D-=20 Gentoo Linux Developer Scientific Applications | AMD64 | KDE | net-proxy --nextPart1479401.qZ0IvdqgVi Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQBCpxplzgRsaX1BF70RAlfpAJ9FKX4qCXytawbPuNgy8KrWlMmvBwCgoNZd Ru0w2neB7ITH5AhtanEOc9Q= =+xev -----END PGP SIGNATURE----- --nextPart1479401.qZ0IvdqgVi-- -- gentoo-dev@gentoo.org mailing list