On Fri, 2006-06-09 at 07:44 -0400, Peter wrote: > Firstly, I think it is very clear that anything in sunrise is experimental > or not supported in the main gentoo tree. That's fine! I don't think any > user who goes through the trouble to set up an overlay would miss that > point. You can't go to o.g.o and not see the disclaimers. And, anyone who > goes through the trouble to svn the overlay, edit make.conf, etc., would > not be an ignorant newbie (no disrespect to newbies intended). Anyone who > fetches the sunrise overlay would know exactly what he/she intends to do > and why. Much different than emerge --sync with keyword x86.
Sorry, but if it isn't supported, it doesn't belong on Gentoo infrastructure. > Secondly, my bias against a third party repository is perhaps unwarranted. > I am sure the bmg site is excellent and the people running it are > well-intentioned and experienced. However, that said, as a user, I have a > higher comfort level staying in the gentoo.realm. Again, you are *proving* the point on why this would be bad. It would be not nearly as well maintained, yet users such as yourself will have this rose-colored perception that "it's from Gentoo, so it must be good." This is the *exact* thing that I am trying to avoid. This will *not* be from Gentoo and it will *not* be good. > Thirdly, the opportunity to be able to publish ebuilds that would > otherwise languish in bugzilla is very exciting. I think it also gives the > bugday people an opportunity to close out bugs. Despite what others have > written, having multi-year old bugs is very counter productive. If > something has not been fixed in so long, it probably either can't be > fixed, or may not even apply anymore. I know this is a generalization, but > if a bug was filed against gentoo 2004.3, who knows if it still applies > with gentoo 2006.0. Especially if there has been little or no activity. Perhaps there is no activity because the interest is not there? Nobody seems to be taking this into account. If you really think your package should be added to the tree, then add yourself to CC, get your friends on CC, drum up some support in the forums, find yourself a developer to proxy maintain for you. We don't need a dumping ground for abandoned or little-use ebuilds. > Personally, I don't see the conflict, or the risk, or the additional work > for devs. In fact, I see the opposite. Removing maintainer-wanted bugs is > a net positive. If that means the proposed ebuild lives in o.g.o that's > fine. Just point users who see the bug over to it. And, if an ebuild > proves to be useful, or popular, it's conceivable that it could ultimately > find its way over to the main tree. Well, I've done about as good as I can do to point out how it would be additional work and a major risk. If you cannot see it, there's not much else I can do. Luckily, a growing number of official developers *do* see the risks and are taking a stand against this egregious waste of time. > As for the more sinister aspects of a rogue ebuild finding its way onto > o.g.o, sure that's a possibility. However, any dev could do the same in > portage because they have commit access (and the problem may not be > caught right away). Moreover, it's possible that an ebuild may be fine, > but a particular version of a package tarball could have outright > malicious code or an undetected security hole in it that has not been > caught yet. That could find its way onto portage too. IMHO, I don't see > any more risk to security in o.g.o. Sure, a developer could be a risk, but they've gone through much more extensive checking and testing than some user who submitted an ebuild to a bug. > Again, I think you need to consider your audience for o.g.o. The newbie > won't be there or be syncing to o.g.o. The server admin probably would not > be there either for updating a production machine. I think the main > audience for o.g.o. would be the power user, or the wannabe power user or > certain project teams, or people with a particular interest or need in a > project not hosted on the main tree -- that is people who actively need > sunrise's services. You're absolutely right. We need to think of the audience. The overlays.gentoo.org project was touted as a way to foster the community and to help *developers* develop things that might be intrusive to the portage tree, as well as allow for easier non-developer contributions. It was *never* touted as a place where we would allow dumping of half-correct, unsupported, and only marginally quality ebuilds for mass user consumption. > And, looking at this from a broader perspective, I see this as a real > enhancement to gentoo. Offering an experimental tree for packages not > intended or not wanted in the main tree. This is an added benefit, it > demonstrates a policy of inclusion, not exclusion. It shows a willingness > to push the envelope and give certain packages a home where they would not > normally get one. It also shows that we're not concerned with quality or providing a consistent experience where things are meant to work together. It shows our complete lack of commitment to the safety of our users. It shows that we really are nothing more than a bunch of ricers that will take the quick and easy approach, rather than doing things right. No thanks... -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
