gen2

Message

micr0c0sm · Post by **micr0c0sm** » Mon Jan 14, 2008 10:52 am

I wrote this, planning on finishing after vacation. My vacation has been extended, and since I have seen some similar ideas thrown up on the forums lately I would like some comments on it.

Code: Select all

name::
    gen2 - a community built meta-distribution

features::
  open community overlay with automatic tracking of package installation success
    fine-grained user configured package stability level
      automatic creation and uploading of binpkgs to speed up package installation

explanation::
	gen2 aims to improve the user and developer experiences of Gentoo. For normal users, their operating system should be up and running as fast as possible. For power users, their operating system should be as configurable as Gentoo while still being fast and stable. For developers, contributing should focus on technical merit and require little effort beyond implementation.

	The largest issue for potential users are an intense initial configuration. By choosing sane defaults to get a system up and running quickly new users should feel welcome and be encouraged to explore the more powerful options at their own pace. Long compile times are add to the time spent working on your system rather than working with your system. By creating automatic binpkgs the more popular programs and settings will install and update quickly. Developers face ineffective quality assurance tools. Paludis and its various clients are excellent for testing ebuilds and other more advanced installation scripts. 

	The largest change in gen2 involves contributors, people who contribute to Gentoo through either official or unofficial means. By replacing the herds with a community repository, the overhead to contribute and maintain ebuilds will be lowered. To keep a high level of stability end users will specify their own fine-grained level s for each package.

	The basic idea is to allow everyone to improve gen2 exactly how much they want to without getting in their way. Passive users will be improving gen2 just by installing ebuilds and uploading success metrics or binpkgs (both opt-out). Active developers will improve gen2 by improving the software themselves, putting effort into projects like Paludis, einit, etc-proposals, etc. Contributors will improve gen2 every time they create or fix an ebuild on their own system. From a technical standpoint, the core gen2 team will just be creating the glue between already great products.

developers::
  core maintains core branch, community branch, live cd, installer
	Jonathan Dehan ( jdehan/gmail )
  web maintains mailing list, website, forum, wiki, planet, universe
	Jonathan Dehan ( jdehan/gmail )

todo::
  core::beta-1
    community repository
	installation of bazaar
	creation of local repository
	sync of core branch read only
	sync of community branch read/write
	post install hook metric reporting in ebuild
	diff commit for ebuild metrics
	reverting all user-specific metric diffs
	checking for sane configuration before reporting
	respect /etc/paludis/package.keywords for dependency resolution (name %/#)
	reporting metric on correct package if dependency fails

    community binpkgs
	checking for available binpkg before installation
	binpkg install if available
	binpkg creation if not available
	check for sane config on binpkg install/creation
	respect /etc/gen2/config BINPKG='temp/10'
	  none/x never installs binpkg
	  fast/x installs x matching compile settings, compiles in background
	  temp/x installs x matching use settings, compiles in background
	  full/x installs x full matches

    livecd
	modify gentoo minimal livecd to include paludis, custom hooks
	add fluxbox, irssi, screen, links2, einit
	add documentation
  web::beta-1
    register domain name
	gen2.org already owned, but willing to give subdomain
	setup mailing list, forums, website, wiki, planet, universe

steveL · Post by **steveL** » Mon Jan 14, 2008 12:53 pm

Who's going to maintain your ebuilds? Or will you just be leeching off Gentoo?

Voltago · Post by **Voltago** » Mon Jan 14, 2008 1:05 pm

Build it and they will come. Best of luck.

micr0c0sm · Post by **micr0c0sm** » Mon Jan 14, 2008 4:51 pm

steveL wrote:Who's going to maintain your ebuilds? Or will you just be leeching off Gentoo?

The initial tree for beta 1 will be just a modified version of the current portage tree. My hope is that as people's favorite software gets updated, they either try making new ebuilds for themselves or the software authors themselves provide ebuilds and that it migrates bottom-up as automatically as possible. There is a huge responsibility on the user base so it's reasonable that gen2 will need to share the tree until it gets more popular. Of course the gen2 tree would be available to herd maintainers with the bonus of testing stats on particular ebuilds.

micr0c0sm · Post by **micr0c0sm** » Mon Jan 14, 2008 4:55 pm

Voltago wrote:Build it and they will come. Best of luck.

Thanks for the kind words.

micr0c0sm · Post by **micr0c0sm** » Mon Jan 14, 2008 5:00 pm

Also note that Paludis is not the only option, it is just the client I am most comfortable with.

steveL · Post by **steveL** » Mon Jan 14, 2008 5:13 pm

micr0c0sm wrote:
steveL wrote:Who's going to maintain your ebuilds? Or will you just be leeching off Gentoo?
The initial tree for beta 1 will be just a modified version of the current portage tree. My hope is that as people's favorite software gets updated, they either try making new ebuilds for themselves or the software authors themselves provide ebuilds and that it migrates bottom-up as automatically as possible. There is a huge responsibility on the user base so it's reasonable that gen2 will need to share the tree until it gets more popular. Of course the gen2 tree would be available to herd maintainers with the bonus of testing stats on particular ebuilds.

So what you mean is you will be using Gentoo software for the foreseeable future, while taking users from Gentoo. I'm not trying to be harsh, I just see that as divisive. You say the tree will be "available to herd maintainers"; what does that mean exactly? Will you be posting bugreports upstream to Gentoo for every ebuild that you use which you find a problem in (after a suitable bug-triage and trouble-shooting process) so that all Gentoo users can benefit? Are you ready for the fact that you might not be so popular with your upstream since you are presenting yourself as a fork, and taking their users on that basis, even though you are not?

Why not just do a user overlay similar to sunrise, or indeed get involved, via #gentoo-sunrise? Don't get me wrong: I think there's plenty of issues with how users get turned off helping. But I see a fork that isn't actually a fork as unhelpful to improving that (cf sabayon). I'd far rather see us users helping each other to report and triage bugs (and yeah back each other up when a dev behaves like a tit) on bugs.gentoo.org. We have every right to be there and to expect common courtesy (if you can't do that, just don't respond.) A user-led overlay would be fun as well; just don't call it a distro or a fork. It's not, since you rely on Gentoo developer work.

micr0c0sm · Post by **micr0c0sm** » Mon Jan 14, 2008 9:31 pm

steveL wrote:
micr0c0sm wrote:
steveL wrote:Who's going to maintain your ebuilds? Or will you just be leeching off Gentoo?
The initial tree for beta 1 will be just a modified version of the current portage tree. My hope is that as people's favorite software gets updated, they either try making new ebuilds for themselves or the software authors themselves provide ebuilds and that it migrates bottom-up as automatically as possible. There is a huge responsibility on the user base so it's reasonable that gen2 will need to share the tree until it gets more popular. Of course the gen2 tree would be available to herd maintainers with the bonus of testing stats on particular ebuilds.
So what you mean is you will be using Gentoo software for the foreseeable future, while taking users from Gentoo. I'm not trying to be harsh, I just see that as divisive.

That is not harsh, and it is divisive, and it is one of the biggest issues I see with gen2.

You say the tree will be "available to herd maintainers"; what does that mean exactly? Will you be posting bugreports upstream to Gentoo for every ebuild that you use which you find a problem in (after a suitable bug-triage and trouble-shooting process) so that all Gentoo users can benefit?

To clarify my earlier response, when I mean the gen2 tree will be available to gentoo herds I meant that user created and tested ebuilds can be checked first by herd maintainers and they could use the ebuilds unmodified so they don't have to write as much of the ebuild.

Are you ready for the fact that you might not be so popular with your upstream since you are presenting yourself as a fork, and taking their users on that basis, even though you are not?

I am very aware of that issue, and open to any suggestions on how to avoid it.

Why not just do a user overlay similar to sunrise, or indeed get involved, via #gentoo-sunrise? Don't get me wrong: I think there's plenty of issues with how users get turned off helping. But I see a fork that isn't actually a fork as unhelpful to improving that (cf sabayon). I'd far rather see us users helping each other to report and triage bugs (and yeah back each other up when a dev behaves like a tit) on bugs.gentoo.org. We have every right to be there and to expect common courtesy (if you can't do that, just don't respond.) A user-led overlay would be fun as well; just don't call it a distro or a fork. It's not, since you rely on Gentoo developer work.

That is an incredible idea! Indeed the 'forking' was the biggest issue I had with gen2, but offering it as an overlay project with some extras would be a great way to enhance the gentoo user experience without detracting from the main distribution. Its hard to classify gen2 as it does rely on the portage tree at least in the beginning, but has a significant change in the community and user interaction with thier system. As a comparison, when someone creates a 'Ubuntu-based' or 'Slackware-based' distribution, they still take most updates from the main distro right? But its still considered a fork.

I also agree that I would rather see users helping each other out and reporting bugs, but in my experience I have seen tons of semi-apathetic users. For these reasons I will first release gen2 as just an overlay, but still want to create a method that doesn't rely on an already installed gentoo (and the stage3's etc...).

To summarize, first and foremost gen2 will be a user-led overlay and will be meant to integrate with an existing gentoo system. Later an installation method using just the main overlay and tools will be supported if there is demand once a solid livecd and tools are created. Both will be officially supported and users will be encouraged to be active participants in the gentoo community.

Thanks for the great ideas steveL!

voxiac · Post by **voxiac** » Mon Jan 14, 2008 10:36 pm

I thought paludis couldn't do binpkgs yet... Also they said that their binpkg wouldn't be compatible with portage binpkgs IIRC.

As I see it you really have several projects here and I'd suggest also make them separate from each other so all Gentooers can use those they like (I for one would be willing to test your error & statistics gathering hooks in paludis). In the end you can always make your own livecds/stages which include all of them (and please make the process of creating those as transparent as possible).

c0d3g33k · Post by **c0d3g33k** » Mon Jan 14, 2008 10:48 pm

steveL wrote:Who's going to maintain your ebuilds? Or will you just be leeching off Gentoo?

This is undeservedly cynical and not a little insulting, given that Gentoo is a self-described 'metadistribution'. In fact this is often used as the rationale for not providing reasonable defaults and configurations - "Gentoo is not a distribution - it's a metadistribution. If you want a usable <insert desired distribution sub-type here>, go make your own".

Yet when someone actually does this, they are accused of "leeching" off of Gentoo (conveniently granted the status of 'true' distribution in this context).

So which way would you have it?

1. Gentoo as a full fledged distribution sufficient able to stand on its own alongside other distributions with respect to out-of-the-box functionality and usability?

2. (True to its own rhetoric) Gentoo as a foundation on which to produce better and more specifically useful distributions without recreating everything (including ebuilds) from scratch?

You can't have it both ways.

steveL · Post by **steveL** » Tue Jan 15, 2008 2:33 am

c0d3g33k wrote:
steveL wrote:Who's going to maintain your ebuilds? Or will you just be leeching off Gentoo?
This is undeservedly cynical and not a little insulting, given that Gentoo is a self-described 'metadistribution'. In fact this is often used as the rationale for not providing reasonable defaults and configurations - "Gentoo is not a distribution - it's a metadistribution. If you want a usable <insert desired distribution sub-type here>, go make your own".

Yeah but if you look at the original post it describes gen2 as "a community built meta-distribution". IOW a complete fork of Gentoo, not a distro based on it.

Yet when someone actually does this, they are accused of "leeching" off of Gentoo (conveniently granted the status of 'true' distribution in this context).

It's leeching when you place yourself in direct competition (as sabayon does by slating Gentoo) or provide exactly the same thing as the original proposal in this case described, and use Gentoo code and maintenance effort to do it. As pointed out above, this wasn't a proposal for a distro based on Gentoo so your premise is incorrect.

So which way would you have it?

1. Gentoo as a full fledged distribution sufficient able to stand on its own alongside other distributions with respect to out-of-the-box functionality and usability?

2. (True to its own rhetoric) Gentoo as a foundation on which to produce better and more specifically useful distributions without recreating everything (including ebuilds) from scratch?

You can't have it both ways.

Yes I can; Gentoo currently does both of those. Sure it takes configuration, so what? Doesn't stop it being very usable. I find it much more reliable and usable than the other distros I used to use, and most especially appreciate that what I get on my desktop is as close as possible to what upstream release.

steveL · Post by **steveL** » Tue Jan 15, 2008 3:35 am

micr0c0sm wrote: To clarify my earlier response, when I mean the gen2 tree will be available to gentoo herds I meant that user created and tested ebuilds can be checked first by herd maintainers and they could use the ebuilds unmodified so they don't have to write as much of the ebuild.

That's not going to be enough imo. To be a valid downstream project you will have to triage bugs in your overlay and when you have found stuff that is a bug upstream you will have to report it as such. It's perfectly fine for you to offer the bug-fixes to your users as soon as you have them, of course, and it's then up to the upstream to use them or not. If they do, and your ebuilds are no different, they should be dropped from the overlay so that the Gentoo ones are used directly.

Indeed the 'forking' was the biggest issue I had with gen2, but offering it as an overlay project with some extras would be a great way to enhance the gentoo user experience without detracting from the main distribution. Its hard to classify gen2 as it does rely on the portage tree at least in the beginning, but has a significant change in the community and user interaction with thier system. As a comparison, when someone creates a 'Ubuntu-based' or 'Slackware-based' distribution, they still take most updates from the main distro right? But its still considered a fork.

I wouldn't consider ubuntu a fork of debian, for example. It's a separate distro (a collation of what is required to install and run Linux) but it works closely with debian so that bug-fixes are incorporated into the parent. The "extras" you mention concern me: what exactly do you mean by that?

I also agree that I would rather see users helping each other out and reporting bugs, but in my experience I have seen tons of semi-apathetic users. For these reasons I will first release gen2 as just an overlay, but still want to create a method that doesn't rely on an already installed gentoo (and the stage3's etc...).

Well those users would be the ones who devs whinge about then ;-) I'm lucky I don't see many of them on irc. We get the odd one in #gentoo-chat who treats it as a private support forum (when it's the off-topic room where we talk all kinds of rubbish;) and often they get helped in the background (I'm typically the one who gets fed up of it and reminds them that #gentoo has 900 people who actually want to help them as opposed to the 60 in #-chat who aren't really there for that) but in the main Gentoo users are used to putting a bit of effort into maintaining their machines.
The real problem I get told about over and over is that when they file bugs they feel mistreated. That's why I proposed something along the lines of wine triage on the dev m-l; so that other users could translate the brusque comments of someone who deals with hundreds of bugs a day and isn't there to discuss either the merits of the filing (beyond assigning it or declaring it a dupe etc.) nor to give instructions. Typically jakub (we all know he's the main culprit ;) does actually provide a fix or a link to one, but he simply doesn't have time to explain stuff. Personally, I'd prefer him to focus on his job and let others support the users (which is what we all do on the forums and irc.)

To summarize, first and foremost gen2 will be a user-led overlay and will be meant to integrate with an existing gentoo system. Later an installation method using just the main overlay and tools will be supported if there is demand once a solid livecd and tools are created. Both will be officially supported and users will be encouraged to be active participants in the gentoo community.

Sounds great, and i look forward to helping you with it. :-)

Insanity5902 · Post by **Insanity5902** » Tue Jan 15, 2008 5:01 am

steveL wrote:Who's going to maintain your ebuilds? Or will you just be leeching off Gentoo?

By that statement, every oss project out there that synchronizes with the parent is a leech.

CentOS is just a leech of Red Hat ...

steveL · Post by **steveL** » Tue Jan 15, 2008 5:32 am

Insanity5902 wrote:
steveL wrote:Who's going to maintain your ebuilds? Or will you just be leeching off Gentoo?
By that statement, every oss project out there that synchronizes with the parent is a leech.

CentOS is just a leech of Red Hat ...

Er CentOS send bug-reports to RH don't they? And correct me if I'm wrong, but RH is a commercial entity and CentOS makes the case for installing their software. As others have pointed out on these forums, enterprises want paid support: you can't get that from CentOS itself, only RH (or a consultancy using CentOS.) So RedHat gains commercially from having CentOS out there, and it's a pretty good way to get the community to test stuff at no expense.

micr0c0sm · Post by **micr0c0sm** » Tue Jan 15, 2008 9:10 am

The ebuilds are not going to be exactly the same as the upstream one, they will have to go through some conversion, and I was under the impression that bugreporting new ebuilds and modified ebuilds would not be welcome by upstream, since they are not going to be the same. If its an automated conversion (just adding statistics and nothing else) from an upstream ebuild of course there will be bugreporting upstream. But otherwise the gen2 tree really isn't gonna have a upstream for most of the ebuilds, once the community starts modifying them.

I get back the 21st so the ball will really get rolling around then ( I idle #gentoo-sunrise, #gen2 ), glad to see some interest in the project.

steveL · Post by **steveL** » Tue Jan 15, 2008 10:18 am

micr0c0sm wrote:The ebuilds are not going to be exactly the same as the upstream one, they will have to go through some conversion, and I was under the impression that bugreporting new ebuilds and modified ebuilds would not be welcome by upstream, since they are not going to be the same. If its an automated conversion (just adding statistics and nothing else) from an upstream ebuild of course there will be bugreporting upstream. But otherwise the gen2 tree really isn't gonna have a upstream for most of the ebuilds, once the community starts modifying them.

Oh, so you're not going to track new releases from Gentoo? That would be a true fork then.
All I'm saying is: if you find a bug in a Gentoo ebuild which you fix in overlay, verify it on a vanilla Gentoo install and report it. It's the least you can do imo.

gentoo-dev · Post by **gentoo-dev** » Tue Jan 15, 2008 11:53 am

Insanity5902 wrote:
steveL wrote:Who's going to maintain your ebuilds? Or will you just be leeching off Gentoo?
By that statement, every oss project out there that synchronizes with the parent is a leech.

CentOS is just a leech of Red Hat ...

Using Gentoo's own infrastructure for a fork could be considered leeching.

BTW, you'd have to find a better name because gen2 looks and sounds too much like Gentoo, i.e. it's infringing on its trademark and if they want to keep they have to defend it.

micr0c0sm · Post by **micr0c0sm** » Tue Jan 15, 2008 6:36 pm

steveL wrote:
micr0c0sm wrote:The ebuilds are not going to be exactly the same as the upstream one, they will have to go through some conversion, and I was under the impression that bugreporting new ebuilds and modified ebuilds would not be welcome by upstream, since they are not going to be the same. If its an automated conversion (just adding statistics and nothing else) from an upstream ebuild of course there will be bugreporting upstream. But otherwise the gen2 tree really isn't gonna have a upstream for most of the ebuilds, once the community starts modifying them.
Oh, so you're not going to track new releases from Gentoo? That would be a true fork then.
All I'm saying is: if you find a bug in a Gentoo ebuild which you fix in overlay, verify it on a vanilla Gentoo install and report it. It's the least you can do imo.

gen2 will not track new ebuilds and add them to the main repository when they are updated. Technically, there is nothing stopping a user from adding an ebuild from gentoo's tree to gen2, but if that user sees a bug and fixes it they will be required to report those upstream (as much as I could enforce it). There are lots of little technicalities that will need to be decided upon with my current repository implementation model, but as much as possible gen2 should have a strong symbiotic relationship with gentoo.

micr0c0sm · Post by **micr0c0sm** » Tue Jan 15, 2008 6:38 pm

gentoo-dev wrote:
Insanity5902 wrote:
steveL wrote:Who's going to maintain your ebuilds? Or will you just be leeching off Gentoo?
By that statement, every oss project out there that synchronizes with the parent is a leech.

CentOS is just a leech of Red Hat ...
Using Gentoo's own infrastructure for a fork could be considered leeching.

BTW, you'd have to find a better name because gen2 looks and sounds too much like Gentoo, i.e. it's infringing on its trademark and if they want to keep they have to defend it.

Names can be changed to protect the innocent, as stated before I want gen2 to have as symbiotic a relationship as possible with the original.

thewtex · Post by **thewtex** » Tue Jan 15, 2008 8:35 pm

gentoo-dev wrote:
Insanity5902 wrote:
steveL wrote:Who's going to maintain your ebuilds? Or will you just be leeching off Gentoo?
By that statement, every oss project out there that synchronizes with the parent is a leech.

CentOS is just a leech of Red Hat ...
Using Gentoo's own infrastructure for a fork could be considered leeching.

BTW, you'd have to find a better name because gen2 looks and sounds too much like Gentoo, i.e. it's infringing on its trademark and if they want to keep they have to defend it.

gen2 has every right to call itself gen2 or even Gentoo. What is currently called Gentoo was not created solely by people who consider themselves 'the developers'. Even though 'the developers' refuse to recognize them, there are other people who exist that have made an much larger contribution to gentoo: the founder, developers they have alienated with their egos, past developers, and 'users'. Keep in mind that this is not a Microsoft project. This is a free/open source project. There is no black and white 'users' and 'developers.' gen2 can be more Gentoo than 'Gentoo'. As far as the trademark goes, apathy and arrogance have made that a non-issue.

I, for one, will be happy to join the project.

Eden · Post by **Eden** » Tue Jan 15, 2008 8:49 pm

Chances are unless you find bugs on vinilla gentoo the gentoo devs will dismiss any bug reports you make any way, even if you did repeat them on vinilla gentoo if they know who you are and that you work on another project they will again ignore it, this is something they made abundently clear to the sabayon devs and users.

As for leaching, maybe people are forgetting that this is a free software community the whole point of that in the fist place is that you share everything.

lxnay · Post by **lxnay** » Tue Jan 15, 2008 10:53 pm

Leeching? What is OSS all about then? We are allowed to leach each others without running into legal troubles.
My advice, go, leech, steal (Free Software) code, change it, hack it, mess it and GIVE BACK.

thewtex · Post by **thewtex** » Wed Jan 16, 2008 12:13 am

lxnay, and Eden,

I have never installed Sabayon, but am downloading it currently and look forward to trying it out. I never had the hardware to, but just got a new box.

micrOcOsm,

You have some really great ideas, and I hope you follow through. Here is what I really like:

Paludis.
Easy to contribute to project.
I'm not sure if I fully understand the community binpkgs, but adding binary package capabilities and choice more natively is great.
The changes to the minimal livecd are all fantastic.
Core/community branches.

Here are some slight, but important suggested improvements.

success metrics opt-in instead of opt-out
git instead of bazaar
I have never used bazaar, but I have heard that there are some technical issues. And it is in python, so it might not scale as well. I have used git, and it is extremely fast and fantastic in many ways.

thewtex · Post by **thewtex** » Wed Jan 16, 2008 7:50 am

The core/community model may not be the best path. We already have that and it will probably eventually lead to the situation we have today.

Instead, base branches on people. Ebuilds/documentation/tools are associated with a GPG signature, and you configure your system to which people you want and where you want to find them. A single individual can also start a group, such as gen2 or a herd, and pick people to add to the group. You can then add groups to your configuration too.

The owner of the ebuild can decide if he wants to mark it as unmodifiable, publicly modifiable, or free to change ownership. This, along with the possibility of extensive slots in the repository, will help with the public overwrite problem.

micr0c0sm · Post by **micr0c0sm** » Wed Jan 16, 2008 9:40 am

thewtex wrote:lxnay, and Eden,

I have never installed Sabayon, but am downloading it currently and look forward to trying it out. I never had the hardware to, but just got a new box.

micrOcOsm,

You have some really great ideas, and I hope you follow through. Here is what I really like:

Paludis.
Easy to contribute to project.
I'm not sure if I fully understand the community binpkgs, but adding binary package capabilities and choice more natively is great.
The changes to the minimal livecd are all fantastic.
Core/community branches.

First, thanks for the kind words, and seeing this much interest I have no choice but to follow through.

The binpkgs would be created postinstall and then the crcs would be verified much like the ebuilds themselves. When a threshold is hit, it is uploaded with some compile-time information so the next person to want that package will install the binpkg first saving time. This will be very strict matching and will only help with the most commonly compiled programs with the most commonly compiled settings, but its a trivial feature to add and I think a cool one. People could also just create their own binpkg servers and as long as you sync to those you can go completely binpkg.

Here are some slight, but important suggested improvements.

I'm all ears.

success metrics opt-in instead of opt-out

I feel like its easier for a person who doesn't want to report successes to edit thier config, than it is for a person who doesn't care to do the same. The feature will be described in the main installation docs so it's easy for people to opt out.

git instead of bazaar
I have never used bazaar, but I have heard that there are some technical issues. And it is in python, so it might not scale as well. I have used git, and it is extremely fast and fantastic in many ways.

git's scaling is widely known to be great, and I would be open to a git implementation. It just seemed for certain features that bazaar fit the overlay model a bit better (and seemed easier to use for someone who has limited SCM experience).

The core/community model may not be the best path. We already have that and it will probably eventually lead to the situation we have today.

Core would essentially just be a *very* small unmodifiable tree. If someone offers a better ebuild and it passes some threshold of successfull installs and percent, it will automatically be sent to the core team and can be added to the core tree.

Instead, base branches on people. Ebuilds/documentation/tools are associated with a GPG signature, and you configure your system to which people you want and where you want to find them. A single individual can also start a group, such as gen2 or a herd, and pick people to add to the group. You can then add groups to your configuration too.

With this kind of model, it seems bazaar would work better. One thing I wanted gen2 to avoid is having to edit a sources.list immediately upon installation to get a workable desktop/server/workstation. I also would not want to have to modify the sources.list during the installation as people had better ebuilds. A default list would have to be maintained and then you are basically getting into the same power structure as gentoo right now. Please correct me if I am missing something. I do agree there needs to be a way to choose individuals but that should be secondary. By specifying a desired stability level, the system should be smart enough to get ebuilds from everyone who registers thier computer as a repository and pick the best ebuild at that time. I have no idea how well this will work in practice but thats what testing is for!

The owner of the ebuild can decide if he wants to mark it as unmodifiable, publicly modifiable, or free to change ownership. This, along with the possibility of extensive slots in the repository, will help with the public overwrite problem.

This would be a nice feature, but I think it is unecessary with the metrics and and system resolution method. I will outline a few sample user interactions and what the system does to resolve conflicts.

All in all, great ideas and discussion. Keep in contact!