| 1 |
> -----Original Message----- |
| 2 |
> From: Michał Górny [mailto:mgorny@g.o] |
| 3 |
> Sent: Wednesday, June 12, 2013 9:51 AM |
| 4 |
> To: Gentoo Developer Mailing List |
| 5 |
> Subject: [gentoo-dev] Over-reliance of Gentoo projects on overlays |
| 6 |
> Hello, |
| 7 |
> |
| 8 |
> I'd like to raise another issue I've met again recently. Shortly put, |
| 9 |
> some of our projects are relying too much on their overlays. The net |
| 10 |
> result is that some of their packages in the tree are not well-tested, |
| 11 |
> semi-broken and users end up being hurt by that. |
| 12 |
|
| 13 |
On the other hand, if those overlays' code, due to lack of sufficient manpower, interest, code quality, or whatever, is not able to bubble up through whatever chain of upstreams, perhaps the broken ebuilds or eclasses should be removed from gx86 or have non-gx86-compatible features masked or removed, so that overlay-specific code or features are maintained downstream, in the overlays that service them. |
| 14 |
|
| 15 |
In short, is it not the idea that non-masked gx86 stable, (and, to a lesser extent, non-masked gx86 ~arch) should contain easy-to-use, working ebuilds for the vast majority of users and standard use-cases, whereas overlays, even official overlays, are free to implement whatever quality standards suit the needs of the projects that administer them? |
| 16 |
|
| 17 |
Although there are clearly some Bad Things about overlays as a means of communicating features to end-users and organizing development, I'm not sure this implies there's anything wrong with the overlay mechanism per-se. These Bad Things may, instead, arise from deficiencies in the modularity of ebuilds or portage itself. |
| 18 |
|
| 19 |
Perhaps you should mention the specific bathwater you'd like to see thrown out, and, from there, folks can help determine where, if anywhere, is the baby? |
| 20 |
|
| 21 |
-gmt |
Archives