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 1LTaYB-0003xl-U1 for garchives@archives.gentoo.org; Sun, 01 Feb 2009 11:31:44 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 151CAE02BF; Sun, 1 Feb 2009 11:31:43 +0000 (UTC) Received: from mail01.home.net.pl (mail01.home.net.pl [62.129.252.11]) by pigeon.gentoo.org (Postfix) with SMTP id 9A3C8E02BF for ; Sun, 1 Feb 2009 11:31:42 +0000 (UTC) Received: from localhost (HELO ?10.10.10.10?) (krzysiek.pawlik.people@home@127.0.0.1) by mail01.home.net.pl with SMTP; Sun, 1 Feb 2009 11:31:40 -0000 Message-ID: <4985881C.2010907@gentoo.org> Date: Sun, 01 Feb 2009 11:31:40 +0000 From: Krzysztof Pawlik Organization: Gentoo User-Agent: Thunderbird 2.0.0.19 (X11/20090105) Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-java@lists.gentoo.org MIME-Version: 1.0 To: Gentoo Java Subject: Re: [gentoo-java] QA: java-experimental References: <498504C0.5080909@gentoo.org> <49857A41.7060409@gentoo.org> <49858190.10505@gentoo.org> In-Reply-To: <49858190.10505@gentoo.org> X-Enigmail-Version: 0.95.7 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigA7B2C7A6C849920D538CBA9B" X-Archives-Salt: 704ca389-8dd1-4208-8ff5-fea8dca7b780 X-Archives-Hash: 3ca1107ea4491d983d49e3c39c7677c2 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA7B2C7A6C849920D538CBA9B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Alistair Bush wrote: > I will look into this at some point. I suppose there are many things w= e > could do to help maintain qa. I suppose we also need more overview of > our contributors. So I might attempt to generate reports, etc of > commits by those users. So.. maybe it's time to re-think the way java-* overlays are used? I'd op= t for "staging" approach: let java-experimental be well, experimental - you don= 't know whenever something will work, is a good idea, you're still working on it,= etc. java-overlay would become a staging ground: after some time (to be define= d) ebuilds would end in main tree. So the ebuild migration would look like: * experimental: fresh stuff * overlay: checked by somebody else (peer reviewed) * main tree: after some time in overlay (like a month) That would enforce from where one can have dependencies in particular ove= rlay, would (hopefully) reduce the size of overlays. Something similar was done: http://overlays.gentoo.org/proj/java/wiki/March_2007_Summary#Changesinove= rlays --=20 Krzysztof Pawlik key id: 0xBC555551 desktop-misc, java, apache, ppc, vim, kernel, python... --------------enigA7B2C7A6C849920D538CBA9B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkmFiBwACgkQgo/w9rxVVVFU1QCdGdRsLotCLYu3Iupu4JGj09FO dFYAnigGajTWgYwPIkoPVjJ91PPWjtTg =pxdT -----END PGP SIGNATURE----- --------------enigA7B2C7A6C849920D538CBA9B--