On Tue January 06 2004 11:17 am, Chris Gianelloni wrote: > On Tue, 2004-01-06 at 11:31, Robert Cole wrote: > > On Tue January 06 2004 8:04 am, Chris Gianelloni wrote: > > > Someone who is NOT a developer, and therefore not held liable. If I > > > add a package to the portage tree, I HAVE to maintina it. That is the > > > current Gentoo policy, and I think a VERY good policy for keeping > > > poor-quality ebuilds out of the tree. > > > > I personally believe this type of management has it's days numbered as > > gentoo grows. > > I respect your opinion, but as far as I can see, Gentoo is sticking with > the idea that having packages which do not have at least one developer > willing to maintain it is a bad idea.
Did I ever say not to have a maintainer? If I did I'm sorry I led you in this direction. I guess what I'm suggesting is separating dev access and ebuild contributer access. Ebuild contributer are a class of dev yes but a class in their own I believe with limited rights to the tree. Creating this class would give you more maintainers with less overhead for the cvs-dev class. > > Are we talking about the same distro here? This is gentoo I'm talking > > about. We all do qc in some form or another whether we report the issue > > or not is a different story. > > No. You do bug reporting when you find something wrong. Quality > Control is something that is done before a product is shipped to make > sure it isn't broken. That's what ACCEPT_KEYWORDS can be for. Is from what I can tell. > > Gentoo is an advanced distro. It's always been easy to end up with a > > broken system. Are you trying to make gentoo into another lindows or > > something? > > I'm just going to leave this alone since it is obvious that you're > flame-baiting. No not really. Didn't mean it as that but as you mentioned further down you can't have it both ways. You can't be an advanced distro using curring/bleeding edge stuff AND be a rock solid distro. It's just not going to happen. Well not automatically that is. You can have an extremely stable gentoo system that pretty darn cutting edge but it takes some effort in working with masking and make.conf. I do it all the time. It just seems you want things rock solid stable out the door with gentoo and automatic. That's not happening at least not now. You can get close without ACCEPT_KEYWORDS though. > > I will say that qc from the devs has evolved to limit the broken systems > > that use to happen more but we would have never gotten to this point > > without breaking a system or 100 now and again. I not saying we should > > continue breaking systems I'm just saying it's not unexpected to get a > > broken package or two now and again even from experienced and trusted > > devs. Mistakes can happen and anyone who uses gentoo should not have a > > problem with that. > > Yes, the quality of developer commits has increased because we have been > making a conscious effort to do so. A broken package or two every now > and then is not usually detrimental as the chaos that would ensue with > having a system as you propose where quantity and speed take precedence > over quality. And the addition of ACCEPT_KEYWORDS helped as well but it's meaning and use seems to be fading away. > This is something that we will eventually face, but for now we prefer > the idea of allowing developers to expand their horizons and contribute > anywhere they see fit. There are some limitations on certain areas > which are considered to be more critical, but in general everyone has > access to the entire tree. And you feel with those controls a dev will be restricted? I don't think so it would just be an extra layer they would have to go through or ask to be setup perm with the access to the new area. They would have to think before acting. > > > The way Gentoo looks at it is simply that if we can't trust you with > > > the whole tree, why should we trust you with any of it? > > > > It's not so much a matter of trust as it is a good security practice. I > > have root access to my linux systems but does that mean I just run as > > root all the time? > > You're just putting words into my mouth here. We're speaking of trust > and professionalism. AT work, do you have access to other people's I can't do that, no one can. I'm restating what I think you are saying but a different way to make sure I understand it. The root analogy is actually so close and a perfect fit here. > email? I'm sure you do, since you say that you are an administrator, > but does that mean you go reading other people's mails? That depends on the system but I get your point. With my everyday access no I can't. When I login with an admin account then I could if the system is insecure like Exchange but can't no matter what if it's something more mature like groupwise. > > If I take your example here I should and everyone should just run as the > > root user on a linux/unix system. Why don't we? Because it's a security > > risk and poor security practice. Same with doing an all or nothing cvs > > access it's just lazy and there is no other way to put it except just > > plain lazy security practices. > > You're speaking out of both sides of your mouth. On one side you want > to make adding ebuilds quicker, and on the other, you want us to > implement measures to slow developer's abilities to work. Which is it? I would like to see fine grain controls and a different group of devs like cvs-dev and ebuild-dev with different access controls. cvs-dev (root cvs access) cvs-dev-games (games area access) cvs-dev-misc (misc access) cvs user cgianelloni a part of cvs-dev-games and cvs-dev-misc just as an example. Again you can only take this as far as administration organization will allow. It can get out of hand too fast if your hard of a dozen area. In that case just full access for simplicity. Then start with ebuild devs ebuild-dev, etc, etc The difference with them is I would want owner level control assigned so that yes you can give them ebuild-dev-games but they only have access to the ebuilds in that area that they've contributed. Robert -- [EMAIL PROTECTED] mailing list
