| 1 |
Alistair Bush wrote: |
| 2 |
> I will look into this at some point. I suppose there are many things we |
| 3 |
> could do to help maintain qa. I suppose we also need more overview of |
| 4 |
> our contributors. So I might attempt to generate reports, etc of |
| 5 |
> commits by those users. |
| 6 |
|
| 7 |
So.. maybe it's time to re-think the way java-* overlays are used? I'd opt for |
| 8 |
"staging" approach: let java-experimental be well, experimental - you don't know |
| 9 |
whenever something will work, is a good idea, you're still working on it, etc. |
| 10 |
java-overlay would become a staging ground: after some time (to be defined) |
| 11 |
ebuilds would end in main tree. |
| 12 |
|
| 13 |
So the ebuild migration would look like: |
| 14 |
* experimental: fresh stuff |
| 15 |
* overlay: checked by somebody else (peer reviewed) |
| 16 |
* main tree: after some time in overlay (like a month) |
| 17 |
|
| 18 |
That would enforce from where one can have dependencies in particular overlay, |
| 19 |
would (hopefully) reduce the size of overlays. |
| 20 |
|
| 21 |
Something similar was done: |
| 22 |
http://overlays.gentoo.org/proj/java/wiki/March_2007_Summary#Changesinoverlays |
| 23 |
|
| 24 |
-- |
| 25 |
Krzysztof Pawlik <nelchael at gentoo.org> key id: 0xBC555551 |
| 26 |
desktop-misc, java, apache, ppc, vim, kernel, python... |
Archives