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 1LTh8b-0000sP-1H for garchives@archives.gentoo.org; Sun, 01 Feb 2009 18:33:46 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6E01AE058C; Sun, 1 Feb 2009 18:33:44 +0000 (UTC) Received: from mailfilter6.ihug.co.nz (mailfilter6.ihug.co.nz [203.109.136.6]) by pigeon.gentoo.org (Postfix) with ESMTP id EF6A2E058C for ; Sun, 1 Feb 2009 18:33:43 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlQBAL+LX0l2XNWh/2dsb2JhbAAIyXKFcoFp X-IronPort-AV: E=Sophos;i="4.37,360,1231066800"; d="scan'208";a="72915697" Received: from 118-92-213-161.dsl.dyn.ihug.co.nz (HELO [10.1.1.3]) ([118.92.213.161]) by smtp.mailfilter6.ihug.co.nz with ESMTP; 02 Feb 2009 07:33:42 +1300 Message-ID: <4985EB09.4070302@gentoo.org> Date: Mon, 02 Feb 2009 07:33:45 +1300 From: Alistair Bush User-Agent: Thunderbird 2.0.0.19 (X11/20090102) 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@lists.gentoo.org Subject: Re: [gentoo-java] QA: java-experimental References: <498504C0.5080909@gentoo.org> <49857A41.7060409@gentoo.org> <49858190.10505@gentoo.org> <4985881C.2010907@gentoo.org> In-Reply-To: <4985881C.2010907@gentoo.org> X-Enigmail-Version: 0.95.7 OpenPGP: url= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 04649f0f-a88f-4daf-8019-10025571b501 X-Archives-Hash: 9a5f4033a1cbe7bef8b8fb684842dc48 Krzysztof Pawlik wrote: > Alistair Bush wrote: > So.. maybe it's time to re-think the way java-* overlays are used? I'd opt 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 defined) > 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 overlay, > would (hopefully) reduce the size of overlays. Yes that would be good. Half the problem is that java-overlay became a huge playground of experimental packages. Just look at all the maven packages. Ive never been able to get maven to work from java-overlay and had to hack and slash my way thru them to get them to install in the first place. My guess is that everyone is guilty of this in some way. (I known I am). Whether it is packages that did work but now don't to the ones that never worked in the first place it doesn't matter. From what I understand java-overlay was meant to help reduce the amount of maintenance we had to do within the gentoo tree. It has been very successful at that, now we just have overlays full..... Here are also things ppl should think about. and implement. 1) If you bump a package, with more than trivial changes (aka you don't finish making them, removing bundled jars, etc, etc) commit it to java-experimental, never java-overlay. I don't care what keywords you give it, if it ain't ready it ain't java-overlay. 2) If you delete (even an outdated ebuild) ensure that there are no reverse dependencies. If you are deleting from java-overlay ensure there are no reverse dependencies within java-overlay and java-experimental. (this seems to have occurred a bit. packages depending on =dev-java/package-1.1.1. only to have 1.1.1 replaced by 1.1.2). I could run on but i've run out of time. > > Something similar was done: > http://overlays.gentoo.org/proj/java/wiki/March_2007_Summary#Changesinoverlays >