I’m going to be short and sweet on this. The last time I checked, Sabayon made you run ~arch, upgrading would break your system, and it was all about bleeding edge gui’s. Sabayon is good for the last. But stay away from it if you want or need stability, or gentoo upgrades.

Currently Gentoo has arch, ~arch, and ~M ( - if not available ).One of the main things people want are security patches only updates. I tend to agree with this, although they should be between arch and ~arch, maybe +arch. Technically a security patch can break things which is why they shouldn’t be considered stable.Regen2 should also have strict rules about what’s what. Alpha products should always be ~M, beta’s and rc’s should be ~arch.

regen2 should support an /etc that’s under version control. something like etckeepercould/should work. Or we could just build our own tool for use with an existing vcs.–This workby Caleb Cushingis licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

I think having weekly tarballs is a great idea. But I’m less concerned about the release schedule of such things for regen2 and more concerned about the system packages that tarballs contain. A new tarball should be released, 1 week after a new glibc or gcc is updated, for sure, but any system package should be enough. Why 1 week? well once they stabilize they will hit a lot more people who are likely to have bugs, and that gives time for bugs to be fixed before tar-ing it.

emerge-ng should be able to build rpms, and debs. regen2 should be the distro that builds other distro’s, not only should it be good at that (gentoo is now) it should be designed for it.–This workby Caleb Cushingis licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.

first I hate repositories, but it is unlikely they will go away. So we must strive to make sure that they are only needed for truly rare things. from my perspective the sunrise repo shouldn’t exist. and vcs builds should be in the tree. regen2 should strive to have everything possible in the tree. when it can’t an overlay should have all the capabilities of the main tree. meaning that an overlay shouldn’t automagically be considered less stable and require the keywording of all the ebuilds in it.

gentoo is a source based distribution, and this is a good thing. why then has the ability to have trunk builds (which has been added to many overlay’s) seem like such a hack? all non-binary program ebuilds in the tree should have a ‘trunk’ version option. emerge –sync should then be able to find out whether trunk has been updated so you can correctly rebuild programs as needed with emerge –ask –verbose –update –deep –newuse world–This workby Caleb Cushingis licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.

In short a concept aimed at forking Gentoo Linux. First some history and my own experiences.Gentoo is a sick adolescent who refuses to acknowledge his illness. Because he refuses to acknowledge the illness he can’t be helped. There are many who have ideas about how to help him. Some of those are wrong.Gentoo’s biggest problem? Democracy. Making it actually work is not easy. Most of the really successful, open source, projects have one or two people at the top.

I’m starting a blog for my thoughts on forking Gentoo Linux here–This workby Caleb Cushingis licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.