I personally think this is a bad idea. I can understand and support links to different overlay repositories, however I do not think that gentoo should host or support overlays on its own infrastructure. For one thing supporting overlays on our infrastructure looks like we are supporting broken ebuilds. This will also lead to more confusion with users who find these official overlays and then the overlays conflict with each other and cause problems that leads to comments like well gentoo should just know how to fix it and make it all work. I also think that this overlay structure will not provide incentives for people to commit to the main tree. They will get their ebuild in an overlay and its hosted on gentoo and distributed to the mirrors. At that point its easy for them to continue to use the overlay. Over time the overlay will diverge more and more from other overlays and even the main tree.
If this still goes forward I think we should look at the debian layout where there is the core product and then the security branches etc. Personally I think this is going to cause more bug reports and less updates to the main tree. I also agree that a hostile fork is unlikely, however it is more possible with the overlay layout as anyone can get an ebuild mirrored on our infrastructure at this point. Another thing to concider is how would people be able to contribute to the overlays? Is there a review process? Is there a checkin process? If no then anyone can post a malicious ebuild that would be a security nightmare. I think this security viewpoint alone is enough to re-evaluate this plan of action. Eric On 14:41 Thu 23 Mar , Stuart Herbert wrote: > Hi Chris, > > On 3/23/06, Chris Gianelloni <[EMAIL PROTECTED]> wrote: > > If some random developer goes out there and creates his own fork of > > catalyst in his overlay, I sure don't want to receive a *single* bug on > > it. Ever. > > Your nightmare scenario seems unavoidable. Enabling per-overlay bug > tracking doesn't stop users posting bugs in bugzilla. It just causes > confusion for users, because they're not sure where to go. Normally, > it's not a problem - because the overlay contributors are normally the > owners of the real package. > > A hostile fork of Catalyst is very much a special case. > > What we could do is say that overlays are for package trees only; ie > they are not general-purpose repositories for holding source trees. > That would ensure that your nightmare scenario is even less likely to > happen, and that if it does, it's through no fault of the overlays > project :) > > Best regards, > Stu > > -- > gentoo-dev@gentoo.org mailing list > >
pgpTLZmlX4YYR.pgp
Description: PGP signature
