Alistair Bush wrote:
> I will look into this at some point.  I suppose there are many things we
> 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 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.

Something similar was done:
http://overlays.gentoo.org/proj/java/wiki/March_2007_Summary#Changesinoverlays

-- 
Krzysztof Pawlik   <nelchael at gentoo.org>   key id: 0xBC555551
desktop-misc, java, apache, ppc, vim, kernel, python...