[gentoo-dev] QA Overlay Layout support.

[Alistair Bush]

Here is an issue that is currently being faced by the java project that
I would like to bring to the attention of everyone.  I have already
discussed this will devs from all pm's.

Intro:

Within the java project we have 2 overlays.  java-overlay and
java-experimental.  java-overlay is mean't to be a "stable" overlay, is
available through layman while java-experimental is the opposite.  We
attempt to not add packages to gentoo unless they are a dependency or an
application to help with maintainability.  We allow newbies access to
java-experimental and there are a number of packages that are difficult
to support so are still very much experimental.

The way we are currently using the overlays results in a hierachy of
gentoo > java-overlay > java-experimental.  Where
packages/eclasses/profiles can be inherited from the previous repository.

Problem:

Repoman currently only checks the current repository/overlay and gentoo.
 This is a problem for java-experimental.

These are the following problems:-

1)  repoman does not find eclasses used to by java-experimental ebuilds
that are located in java-overlay.  see [1] for error.  Maintaining the
eclass in multiple locations _is not a solution_.(zmedico is expecting
to add repository support at some point with support for specifying
ECLASSDIRS.  So this issue may be resolved).

2)  repoman does not find packages used to by java-experimental ebuilds
that are located in java-overlay.

Now this might be a result of the package not existing within gentoo or
as a result of a particular version/slot being available within
java-overlay.  Now zmedico suggested that the use of repository deps (
aka ::java-overlay )  could be the solution.  I would rather this not be
the solution as packages shouldn't need to be edited to more them
between overlays.  Also the dependency specified could be moved into gentoo.


Possible Solution:

Now im going to shoot myself in the foot here by mentioning the
unmentionable.

( -->> ) paludis ( <<-- ) currently has support for specifying an
overlays parent(s) (master_repository) within an overlays
metadata/layout.conf file.   Now i'm not suggesting that paludis's
implementation is the correct one,  but I believe the concept is solid.
 By specifying an overlays parent repositories would allow (at least):

1)  emerge to error if that repository/overlay is not configured.; and
2) repoman to locate packages by checking the current overlay, gentoo as
well as the parents specified within an "overlay metadata file"

Possible Solution:

Merging java-overlay and java-experimental.  From my perspective this
isn't a good one as we loss most of the benefits of java-experimental.

Discussion:

Do you support the "overlay metadata file" concept?
Are there any other possible solutions?
Is there anything stopping this from being implemented?  another EAPI?
profile EAPI?
Is there anything else that would benefit from an "overlay metadata
file"?  Default conf variables e.g ECLASSDIRS.
Any other comments?


Thanks
ali_bush

Alistair Bush
Gentoo Linux Developer

[1]
* ERROR: dev-java/commons-jelly-tags-util-1.0 failed.

 * Call stack:

 *ebuild.sh, line 1881:  Called source
'/home/alistair/gentoo/overlays/java-experimental/dev-java/commons-jelly-tags-util/commons-jelly-tags-util-1.0.ebuild'


 *   commons-jelly-tags-util-1.0.ebuild, line7:  Called inherit
'commons-jelly-tags-2'

 *ebuild.sh, line 1238:  Called qa_source
'/home/alistair/gentoo/overlays/java-experimental/eclass/commons-jelly-tags-2.eclass'


 *ebuild.sh, line   37:  Called source
'/home/alistair/gentoo/overlays/java-experimental/eclass/commons-jelly-tags-2.eclass'


 *  commons-jelly-tags-2.eclass, line   30:  Called inherit
'java-pkg-2' 'java-ant-2' 'java-maven-2'

 *ebuild.sh, line 1215:  Called die

 * The specific snippet of code:

 *  [ ! -e "$location" ] && die "${1}.eclass could not be
found by inherit()"
 *  The die message:

 *   java-maven-2.eclass could not be found by inherit()

 *

 * If you need support, post the topmost build error, and the call stack
if relevant.
 * This ebuild used the following eclasses from overlays:

 *
/home/alistair/gentoo/overlays/java-experimental/eclass/commons-jelly-tags-2.eclass

 *
/home/alistair/gentoo/overlays/java-experimental/eclass/java-pkg-2.eclass

 *
/home/alistair/gentoo/overlays/java-experimental/eclass/java-utils-2.eclass

 * This ebuild is from an overlay:
'/home/alistair/gentoo/overlays/java-experimental/'

[2]
dev-java/glazedlists/glazedlists-1.7.0-r2.ebuild:
~amd64(default/linux/amd64/2008.0/server) ['dev-java/swingx']

dev-java/swingx is located in java-overlay.

Re: [gentoo-dev] QA Overlay Layout support.

[Jorge Manuel B. S. Vicetto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alistair Bush wrote:
> Here is an issue that is currently being faced by the java project that
> I would like to bring to the attention of everyone.  I have already
> discussed this will devs from all pm's.
> 
> Intro:
> 
> Within the java project we have 2 overlays.  java-overlay and
> java-experimental.  java-overlay is mean't to be a "stable" overlay, is
> available through layman while java-experimental is the opposite.  We
> attempt to not add packages to gentoo unless they are a dependency or an
> application to help with maintainability.  We allow newbies access to
> java-experimental and there are a number of packages that are difficult
> to support so are still very much experimental.

Sorry for taking so long to reply to the mail.
The KDE team had followed the Java example, but has since been forced to
merge the 2 overlays together, exactly because of the issues discussed
in this mail.

> The way we are currently using the overlays results in a hierachy of
> gentoo > java-overlay > java-experimental.  Where
> packages/eclasses/profiles can be inherited from the previous repository.
> 
> Problem:
> 
> Repoman currently only checks the current repository/overlay and gentoo.
>  This is a problem for java-experimental.

Agreed.

> These are the following problems:-
> 
> 1)  repoman does not find eclasses used to by java-experimental ebuilds
> that are located in java-overlay.  see [1] for error.  Maintaining the
> eclass in multiple locations _is not a solution_.(zmedico is expecting
> to add repository support at some point with support for specifying
> ECLASSDIRS.  So this issue may be resolved).
> 
> 2)  repoman does not find packages used to by java-experimental ebuilds
> that are located in java-overlay.
> 
> Now this might be a result of the package not existing within gentoo or
> as a result of a particular version/slot being available within
> java-overlay.  Now zmedico suggested that the use of repository deps (
> aka ::java-overlay )  could be the solution.  I would rather this not be
> the solution as packages shouldn't need to be edited to more them
> between overlays.  Also the dependency specified could be moved into gentoo.

Repository deps would be very helpful. They could be used to "link"
packages in an overlay to packages in another overlay.

> Possible Solution:
> 
> Now im going to shoot myself in the foot here by mentioning the
> unmentionable.
> 
> ( -->> ) paludis ( <<-- ) currently has support for specifying an
> overlays parent(s) (master_repository) within an overlays
> metadata/layout.conf file.   Now i'm not suggesting that paludis's
> implementation is the correct one,  but I believe the concept is solid.
>  By specifying an overlays parent repositories would allow (at least):
> 
> 1)  emerge to error if that repository/overlay is not configured.; and
> 2) repoman to locate packages by checking the current overlay, gentoo as
> well as the parents specified within an "overlay metadata file"
> 
> Possible Solution:
> 
> Merging java-overlay and java-experimental.  From my perspective this
> isn't a good one as we loss most of the benefits of java-experimental.

I agree, but that's what we (KDE) were forced to do.

> Discussion:
> 
> Do you support the "overlay metadata file" concept?
> Are there any other possible solutions?
> Is there anything stopping this from being implemented?  another EAPI?
> profile EAPI?
> Is there anything else that would benefit from an "overlay metadata
> file"?  Default conf variables e.g ECLASSDIRS.
> Any other comments?
> 
> 
> Thanks
> ali_bush
> 
> Alistair Bush
> Gentoo Linux Developer
> 
> [1]
> * ERROR: dev-java/commons-jelly-tags-util-1.0 failed.
> 
>  * Call stack:
> 
>  *ebuild.sh, line 1881:  Called source
> '/home/alistair/gentoo/overlays/java-experimental/dev-java/commons-jelly-tags-util/commons-jelly-tags-util-1.0.ebuild'
> 
> 
>  *   commons-jelly-tags-util-1.0.ebuild, line7:  Called inherit
> 'commons-jelly-tags-2'
> 
>  *ebuild.sh, line 1238:  Called qa_source
> '/home/alistair/gentoo/overlays/java-experimental/eclass/commons-jelly-tags-2.eclass'
> 
> 
>  *ebuild.sh, line   37:  Called source
> '/home/alistair/gentoo/overlays/java-experimental/eclass/commons-jelly-tags-2.eclass'
> 
> 
>  *  commons-jelly-tags-2.eclass, line   30:  Called inherit
> 'java-pkg-2' 'java-ant-2' 'java-maven-2'
> 
>  *ebuild.sh, line 1215:  Called die
> 
>  * The specific snippet of code:
> 
>  *  [ ! -e "$location" ] && die "${1}.eclass could not be
> found by inherit()"
>  *  The die message:
> 
>  *   java-maven-2.eclass could not be found by inherit()
> 
>  *
> 
>  * If you need support, post the topmost build error, and the call stack
> if relevant.
>  * This ebuild used the following eclasses from overlays:
> 
>  *
> /home/alistair/gentoo/overlays/java-experimental/

Re: [gentoo-dev] QA Overlay Layout support.

[Donnie Berkholz]

On 11:59 Sun 25 Jan , Alistair Bush wrote:
> Possible Solution:
> 
> Merging java-overlay and java-experimental.  From my perspective this
> isn't a good one as we loss most of the benefits of java-experimental.

Combine this with package.mask. To me, experimental means masked.

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com


pgpLHb6tIrr5j.pgp
Description: PGP signature

Re: [gentoo-dev] QA Overlay Layout support.

[Alistair Bush]

Donnie Berkholz wrote:

On 11:59 Sun 25 Jan , Alistair Bush wrote:

Possible Solution:

Merging java-overlay and java-experimental.  From my perspective this
isn't a good one as we loss most of the benefits of java-experimental.


Combine this with package.mask. To me, experimental means masked.



Experimental within java means a lot of things,  or at least it should. 
 Anything from user contributed and non-dev qa'd to packages with 
bundled jars to attempts to package projects like maven which are 
difficult and time consuming ( and which attempts to do so have failed 
numerous times before might I add ).


Asking non-dev contributors to handle package.mask's would be a "less 
than ideal". Resulting in "interesting breakages".  Currently by adding 
java-experimental ( which might I add isn't available thru layman ) you 
are accepting that risk.


At least java and kde have need of this,  and I could imagine sunrise 
could also use this ( either now or in the future ).


I have implemented a patch [1] tho support this from a repoman 
perspective but believe its benefits could go much further.
Eventually I hope that zmedico will accept it, once he has a chance to 
consider it and I have time to clean it up.


Once repository support is implemented (this is very much depending on 
the details of the implementation) I will start making a patch to will 
have portage check whether an overlays parents are "before" that overlay.


ali_bush

[1] http://dev.gentoo.org/~ali_bush/portage_parent_repo_support.patch

Re: [gentoo-dev] QA Overlay Layout support.

[Donnie Berkholz]

On 19:18 Mon 02 Mar , Alistair Bush wrote:
> Donnie Berkholz wrote:
>> Combine this with package.mask. To me, experimental means masked.
>
> Experimental within java means a lot of things,  or at least it should.  
> Anything from user contributed and non-dev qa'd to packages with bundled 
> jars to attempts to package projects like maven which are difficult and 
> time consuming ( and which attempts to do so have failed numerous times 
> before might I add ).
>
> Asking non-dev contributors to handle package.mask's would be a "less  
> than ideal". Resulting in "interesting breakages".  Currently by adding  
> java-experimental ( which might I add isn't available thru layman ) you  
> are accepting that risk.

I don't understand the distinction you're making here. Either way, users 
explicitly take a manual action to enable additional experimental 
packages (unmasking or adding an overlay full of them). In fact, I see 
the separate-overlay option as worse because then you get *everything* 
from the overlay, whereas package.mask is more granular and can be 
fine-tuned per-package.

Could you explain what you see as the important difference that makes 
package.mask bad and a separate overlay good?

-- 
Thanks,
Donnie

Donnie Berkholz
Developer, Gentoo Linux
Blog: http://dberkholz.wordpress.com


pgpd33P1B6Dqm.pgp
Description: PGP signature

Re: [gentoo-dev] QA Overlay Layout support.

[Alistair Bush]

Donnie Berkholz wrote:

On 19:18 Mon 02 Mar , Alistair Bush wrote:

Donnie Berkholz wrote:


Could you explain what you see as the important difference that makes 
package.mask bad and a separate overlay good?




Contributors sometimes have difficulty following standards (hell even 
dev's do).  I have little confidence that would also be able to actually 
add packages to package.mask without breaking anything else.
As an example we had a contributor break the manifests of a dozen or so 
packages because he updated the Copyright header then couldn't get the 
ebuild to manifest.  I can imagine someone committing dev-java/ant-core 
to the file.  That and there are 325 ebuilds [1] in java-experimental. 
Masking even 1/2 of them separately would be a complete nightmare.


I also note that sunrise doesn't seem to do this either.

Also no ebuilds are ever marked stable,  so it should be easy for 
someone to just add an entry in their package.keywords file.


And what is stopping a user from wanting to have their own overlay, that 
uses java-overlay ( or java-experimental or any other overlay ) 
packages.  Are we to say that we shouldn't allow tools to have support 
for this.  I think that it is a nature progression that if we are to 
allow overlays to extend the portage tree that we should allow overlays 
to extend other overlays.


[1] java-experimental $ find . -iname '*.ebuild' | wc -l

Re: [gentoo-dev] QA Overlay Layout support.

[Jorge Manuel B. S. Vicetto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Alistair Bush wrote:
> 
> 
> Donnie Berkholz wrote:
>> On 19:18 Mon 02 Mar , Alistair Bush wrote:
>>> Donnie Berkholz wrote:
>>
>> Could you explain what you see as the important difference that makes
>> package.mask bad and a separate overlay good?
>>
> 
> Contributors sometimes have difficulty following standards (hell even
> dev's do).  I have little confidence that would also be able to actually
> add packages to package.mask without breaking anything else.
> As an example we had a contributor break the manifests of a dozen or so
> packages because he updated the Copyright header then couldn't get the
> ebuild to manifest.  I can imagine someone committing dev-java/ant-core
> to the file.  That and there are 325 ebuilds [1] in java-experimental.
> Masking even 1/2 of them separately would be a complete nightmare.
> 
> I also note that sunrise doesn't seem to do this either.
> 
> Also no ebuilds are ever marked stable,  so it should be easy for
> someone to just add an entry in their package.keywords file.
> 
> And what is stopping a user from wanting to have their own overlay, that
> uses java-overlay ( or java-experimental or any other overlay )
> packages.  Are we to say that we shouldn't allow tools to have support
> for this.  I think that it is a nature progression that if we are to
> allow overlays to extend the portage tree that we should allow overlays
> to extend other overlays.
> 
> [1] java-experimental $ find . -iname '*.ebuild' | wc -l
> 

To put some perspective from KDE side:

find /home/gentoo-cvs/kde-git/kde -iname *.ebuild | wc -l
330

Also, having separate overlays would allow one to do experimental stuff
with eclasses in the experimental overlay without affecting users of the
base overlay. Until we get versioned eclasses, I don't see how one can
do that with a single overlay.
Last, but not least, as Alistair explained, mixing everything together
confuses users. We've had a few issues with users because of that. In
fact, that was the main reason to start the whole package.mask as a dir
deal.

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmrpxYACgkQcAWygvVEyAKIWwCfSx3CzUPlb9hG4k94m5clrYrT
AUYAoI6j/0V9tla5UwYbOirrzMcvP26u
=mEy0
-END PGP SIGNATURE-

Re: [gentoo-dev] QA Overlay Layout support.

[Thomas Sachau]

Alistair Bush schrieb:
> Asking non-dev contributors to handle package.mask's would be a "less
> than ideal". Resulting in "interesting breakages".  Currently by adding
> java-experimental ( which might I add isn't available thru layman ) you
> are accepting that risk.
> 
> At least java and kde have need of this,  and I could imagine sunrise
> could also use this ( either now or in the future ).

> Contributors sometimes have difficulty following standards (hell even
> dev's do).  I have little confidence that would also be able to actually
> add packages to package.mask without breaking anything else.
> As an example we had a contributor break the manifests of a dozen or so
> packages because he updated the Copyright header then couldn't get the
> ebuild to manifest.  I can imagine someone committing dev-java/ant-core
> to the file.  That and there are 325 ebuilds [1] in java-experimental.
> Masking even 1/2 of them separately would be a complete nightmare.
>
> I also note that sunrise doesn't seem to do this either.

Just to explain it a bit, also it should be documented in the docs (if not, 
patches are welcome):

Sunrise has the sunrise/ tree, where you can only read and write with a 
password (=reading our
HowtoCommit and having an ebuild reviewed). All initial commits go into this 
part, but since this is
only internal, the commits cannot harm any user.
For the second step, we have the reviewed/ tree, which is public and used by 
layman. The sunrise/
tree is reviewed by the sunrise devs and after all commits where reviewed, the 
changes in sunrise/
where merged into reviewed/.
Since the packages are still experimental (we only do a basic review on the 
ebuilds), we only allow
and accept ~ARCH for normal ebuilds and no KEYWORDS for live ebuilds. This way, 
a stable user has to
explicitly keyword a package, before he can install it from sunrise.

Since this is a different concept then those of kde and java (where users can 
add code without some
basic qa check and review), i dont see a need for your request on sunrise side, 
but if i missed
something, feel free to enlighten me.


-- 
Thomas Sachau

Gentoo Linux Developer



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] QA Overlay Layout support.

[Wulf C. Krueger]

On Monday, 02. March 2009 10:29:59 Jorge Manuel B. S. Vicetto wrote:
> Also, having separate overlays would allow one to do experimental stuff
> with eclasses in the experimental overlay without affecting users of the
> base overlay. Until we get versioned eclasses, I don't see how one can
> do that with a single overlay.

You've used it yourself before in GenKDEsvn. :-)

We have a private git repository for development. Any commit in its master 
branch gets auto-pushed by a simple hook to the public repository which is the 
overlay.

Any other branches in the private overlay stay just there. They're not 
publicly visible by default but they *can* be published for guinea pigs who 
feel like suffering. Once the the experimental stuff is safe enough for the 
public overlay, merge that branch to master and - swoosh!

Best regards, Wulf



signature.asc
Description: This is a digitally signed message part.

Re: [gentoo-dev] QA Overlay Layout support.

[Caleb Cushing]

>  Are we to say that we shouldn't allow tools to have support for this.  I
> think that it is a nature progression that if we are to allow overlays to
> extend the portage tree that we should allow overlays to extend other
> overlays.

I probably shouldn't butt in...

first, no I don't want you to merge java-overlay and
java-experimental, that's a bad idea (well at least for me)

second. I generally think anything beyond a personal overlay is crap.
All these overlays like sunrise, java-overlay, and on and on...
basically official, overlays that have qa and are pretty stable. are
crap. they should be in the tree. an overlay for developers is fine,
you know. where you are working on stuff... stuff that someone who
wouldn't want to hack on it wouldn't want, because it's too broken.

but one of the few good things about gentoo, in relation to other
distro's, 1 tree no repos, continues to fall further and further
apart.

-- 
Caleb Cushing

http://xenoterracide.blogspot.com

Re: [gentoo-dev] QA Overlay Layout support.

[Marijn Schouten (hkBst)]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Caleb Cushing wrote:
>>  Are we to say that we shouldn't allow tools to have support for this.  I
>> think that it is a nature progression that if we are to allow overlays to
>> extend the portage tree that we should allow overlays to extend other
>> overlays.
> 
> I probably shouldn't butt in...
> 
> first, no I don't want you to merge java-overlay and
> java-experimental, that's a bad idea (well at least for me)

If you think neither should exist why do you have an opinion about this at all?

> second. I generally think anything beyond a personal overlay is crap.
> All these overlays like sunrise, java-overlay, and on and on...
> basically official, overlays that have qa and are pretty stable. are
> crap. they should be in the tree. an overlay for developers is fine,
> you know. where you are working on stuff... stuff that someone who
> wouldn't want to hack on it wouldn't want, because it's too broken.

What makes you think that overlays aren't for developers, aspiring developers
and interested users where they are working on stuff? It is desirable IMO that
all such people can easily be given full access to muck around and learn.
Further, overlays are good places to put ebuilds for software that is more
experimental than what's expected for ~arch. That includes live ebuilds. In the
end, overlays have a (far) lower level of guaranteed quality than the main tree,
for their ebuilds.

> but one of the few good things about gentoo, in relation to other
> distro's, 1 tree no repos, continues to fall further and further
> apart.

The only thing I see is that the flow of ebuilds from overlays into the main
tree, when they and their software have reached sufficient quality, is sometimes
slow because of lack of developer manpower. For example, Common Lisp is almost
entirely maintained in the lisp overlay and I have the impression that the
Haskell team is having similar issues with many of their former developers no
longer working on Gentoo.

I might even argue that Funtoo is one big overlay. When your own ability to
contribute directly depends on an overlay, then why are you arguing against
other people's overlays?

Marijn


- --
Sarcasm puts the iron in irony, cynicism the steel.

Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
, #gentoo-{lisp,ml} on FreeNode
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmtDPUACgkQp/VmCx0OL2z6lwCdHqP2shPhD91HU9Ld+f/Ma+K3
/6YAnR0cMKEXkqF3ZzA4hkahkPmTQYxR
=MVhI
-END PGP SIGNATURE-

Re: [gentoo-dev] QA Overlay Layout support.

[Petteri Räty]

Caleb Cushing wrote:
>>  Are we to say that we shouldn't allow tools to have support for this.  I
>> think that it is a nature progression that if we are to allow overlays to
>> extend the portage tree that we should allow overlays to extend other
>> overlays.
> 
> I probably shouldn't butt in...
> 
> first, no I don't want you to merge java-overlay and
> java-experimental, that's a bad idea (well at least for me)
> 
> second. I generally think anything beyond a personal overlay is crap.
> All these overlays like sunrise, java-overlay, and on and on...
> basically official, overlays that have qa and are pretty stable. are
> crap. they should be in the tree. an overlay for developers is fine,
> you know. where you are working on stuff... stuff that someone who
> wouldn't want to hack on it wouldn't want, because it's too broken.
> 

Please point me to the people willing and having the time to maintain
those >100 new ebuilds in the main tree.

Regards,
Petteri



signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] QA Overlay Layout support.

[Jorge Manuel B. S. Vicetto]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Wulf C. Krueger wrote:
> On Monday, 02. March 2009 10:29:59 Jorge Manuel B. S. Vicetto wrote:
>> Also, having separate overlays would allow one to do experimental stuff
>> with eclasses in the experimental overlay without affecting users of the
>> base overlay. Until we get versioned eclasses, I don't see how one can
>> do that with a single overlay.
> 
> You've used it yourself before in GenKDEsvn. :-)
> 
> We have a private git repository for development. Any commit in its master 
> branch gets auto-pushed by a simple hook to the public repository which is 
> the 
> overlay.

That's one way to do it and as you say, we've used it before
successfully. An alternative could be to use different branches in the
same repo. We've used it before in the KDE git overlay, but it can get
tricky.
In some cases though, one might want to make the "experimental" work
available to some users (with a big fat warning). The above alternatives
don't allow this or make it complex.
One of the reasons we had to split the work in the 2 overlays was to
move the live ebuilds to the experimental overlay so that "casual users"
wouldn't be affected by them.

> Any other branches in the private overlay stay just there. They're not 
> publicly visible by default but they *can* be published for guinea pigs who 
> feel like suffering. Once the the experimental stuff is safe enough for the 
> public overlay, merge that branch to master and - swoosh!
> 
> Best regards, Wulf
> 

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / SPARC / KDE
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkmvMGEACgkQcAWygvVEyAL0FACfemf/O3oCw4A1ZTIgOEMOFk8l
WNIAn21IHSdV5R4dLJZY0/yXwirI3sQi
=Pm+a
-END PGP SIGNATURE-

Re: [gentoo-dev] QA Overlay Layout support.

[Caleb Cushing]

On Wed, Mar 4, 2009 at 8:52 PM, Jorge Manuel B. S. Vicetto
 wrote:
> One of the reasons we had to split the work in the 2 overlays was to
> move the live ebuilds to the experimental overlay so that "casual users"
> wouldn't be affected by them.

if they're properly masked/keyworded why would 'casual' users be
affected by them?

-- 
Caleb Cushing

http://xenoterracide.blogspot.com