From: "Tomáš Chvátal" <tomas.chvatal@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf
Date: Sun, 10 Feb 2013 15:37:44 +0100 [thread overview]
Message-ID: <1680130.pEs1zspV9T@arcarius> (raw)
In-Reply-To: <511797C4.3010208@plaimi.net>
Dne Ne 10. února 2013 13:51:16, Alexander Berntsen napsal(a):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> On 10/02/13 12:47, Patrick Lauer wrote:
> > So instead of moving things from random overlays to the tree we
> > remove packages now, remove features from other packages because of
> >
> > that (openfoam) and then ... tell users to use an overlay?
> >
> > Somehow this appears not well thought out to me.
>
> +1
>
> On 10/02/13 13:11, Rich Freeman wrote:
> > There is nothing wrong with having an overlay that provides a
> > better experience than the main tree. Most distros actually
> > operate this way
>
> Most distros aren't very good.
>
> > - just look up your average non-core piece of FOSS software and the
> >
> > first thing their Ubuntu install instructions will tell you to do
> >
> > is to add some repository to your list.
>
> And the second search result is the Ubuntu troubleshooting broken
> installs as a result of adding other repositories.
>
> I accept that there may exist reasons for using overlays. "Ubuntu do
> it!" is not one.
>
Don't worry,
no matter what are Richs opinions he is not the one crating global policies
for this, so the defaults still are that we encourage adding all stuff to main
tree where possible. Even the overlays are supposed to be just plaingrounds
where we train upcoming devs, or pose as live ebuild/huge experimantal changes
storage space.
Even the excuse that it is not maintained so it is to stay in overlay is
false, because when somebody mess with the package in overlay they can became
maintainers in the main tree too without much fuzz.
But I suppose this problem is created simply because people not wanting to
work with cvs (and I purely agree that git workflow is much easier wrt
this)...
Cheers
Tom
next prev parent reply other threads:[~2013-02-10 14:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-02-10 9:01 [gentoo-dev] Lastrites: media-gfx/picasa, dev-python/papyon, net-voip/telepathy-butterfly, sci-visualization/paraview, x11-misc/xdaf Pacho Ramos
2013-02-10 11:47 ` Patrick Lauer
2013-02-10 11:48 ` Michał Górny
2013-02-10 12:11 ` Rich Freeman
2013-02-10 15:10 ` Ben de Groot
2013-02-10 16:18 ` Rich Freeman
2013-02-10 11:59 ` Pacho Ramos
2013-02-10 15:05 ` hasufell
2013-02-10 15:08 ` Pacho Ramos
2013-02-10 15:59 ` Peter Stuge
2013-02-10 12:12 ` Tomáš Chvátal
2013-02-10 15:48 ` Peter Stuge
2013-02-10 18:34 ` Alec Warner
2013-02-10 19:50 ` Peter Stuge
2013-02-10 12:51 ` Alexander Berntsen
2013-02-10 13:26 ` Rich Freeman
2013-02-10 14:37 ` Tomáš Chvátal [this message]
2013-02-10 14:49 ` Rich Freeman
2013-02-10 14:42 ` [gentoo-dev] Re: [gentoo-dev-announce] " hasufell
2013-02-10 20:21 ` James Cloos
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=1680130.pEs1zspV9T@arcarius \
--to=tomas.chvatal@gmail.com \
--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