public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: <gmt@malth.us>
To: <gentoo-dev@lists.gentoo.org>
Subject: RE: [gentoo-dev] Over-reliance of Gentoo projects on overlays
Date: Wed, 12 Jun 2013 13:32:30 -0700	[thread overview]
Message-ID: <015b01ce67ab$f6e98250$e4bc86f0$@malth.us> (raw)
In-Reply-To: <20130612185126.15f142b0@gentoo.org>

> -----Original Message-----
> From: Michał Górny [mailto:mgorny@gentoo.org]
> Sent: Wednesday, June 12, 2013 9:51 AM
> To: Gentoo Developer Mailing List
> Subject: [gentoo-dev] Over-reliance of Gentoo projects on overlays 
> Hello,
> 
> I'd like to raise another issue I've met again recently. Shortly put, 
> some of our projects are relying too much on their overlays. The net 
> result is that some of their packages in the tree are not well-tested, 
> semi-broken and users end up being hurt by that.

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.

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?

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.

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?

-gmt




  parent reply	other threads:[~2013-06-12 20:32 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-12 16:51 [gentoo-dev] Over-reliance of Gentoo projects on overlays Michał Górny
2013-06-12 16:59 ` hasufell
2013-06-12 17:02   ` Ciaran McCreesh
2013-06-12 17:05     ` hasufell
2013-06-12 17:13       ` Ciaran McCreesh
2013-06-12 17:19         ` hasufell
2013-06-12 17:23         ` Michael Orlitzky
2013-06-13  4:56           ` Alexander V Vershilov
2013-06-13  6:51             ` Dirkjan Ochtman
2013-06-16  4:08               ` "Paweł Hajdan, Jr."
2013-06-16  7:36                 ` Alexander V Vershilov
2013-06-17  0:50                   ` "Paweł Hajdan, Jr."
2013-06-15  3:32             ` Michael Orlitzky
2013-06-13  5:44           ` Michał Górny
2013-06-13  8:29             ` René Neumann
2013-06-12 20:10   ` Andreas K. Huettel
2013-06-13  3:37     ` Rich Freeman
2013-06-12 20:32 ` gmt [this message]
2013-06-29 18:22 ` Thomas Kahle

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='015b01ce67ab$f6e98250$e4bc86f0$@malth.us' \
    --to=gmt@malth.us \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox