Peter Stuge posted on Tue, 22 Oct 2013 05:19:01 +0200 as excerpted: > Rich Freeman wrote:
>> [Peter Stuge posted...] >>> >>> Everything in the Gentoo project is per definition strictly >>> developer-only. I suppose that it's a function of having the project >>> centered around a foundation. >> >> I can't think of any reason that the Foundation would have anything to >> do with who can and cannot participate in anything related to Gentoo. Good catch. I was confused by that wording as well, but thought of "foundation" in the sense of (physical) underlying superstructure as opposed to (social/legal) organization, because "Gentoo Foundation" in the social/legal sense, for those knowing about it at all, indeed doesn't make sense here. But it's good to put an end to that speculation directly, since otherwise it's likely spread further confusion in the future. > The reason I had in mind is indeed the all-or-nothing security model for > the publications (ebuilds is what I had in mind, I should have written > "Everything I know in the Gentoo project...", sorry about that!) where > even Copyright seems to have to be assigned to the foundation. That has actually been debated here from time to time, and the general agreement seems to be that assigning copyright to the Gentoo Foundation is recommended (for various reasons), but specifically *NOT* required, in part because some gentoo devs (Greg KH was one who specifically stated he'd probably have to resign from being a gentoo dev in that case, I'd guess due to the work-for-hire clauses in his employment contract which allow him to contribute to FLOSS projects but NOT to surrender copyright, which as a work-for-hire, remains with his employer) would very likely be unable to participate were that the case. While there's also ethical arguments to be made on either side, the practical effect of triggering the resignation of multiple gentoo devs were copyright assignment forced, basically put an end to the discussion. >> Gentoo projects have involved non-developers from time to time. The >> documentation project even gives commit access to non-developers, > > Awesome! I'm really glad that I was wrong about that - but at the same > time documentation tends to serve a bootstrapping function, > and thus matter less over time. [The actual reason I bothered replying as it's core to the debate at hand.] It's worth noting that one of the big reasons projects use overlays is to allow non-devs more, in some cases basically full, access. As covered below that's simply not practical in the main tree, but under the relatively narrower confines and tighter direct supervision of a project overlay, active project users very often work hand in hand with full gentoo devs as effective co-equals in the project overlay. Of course users do have to have a bit of history with the project before they gain that level of trust, but once they get it, they may well get full access to the overlay, with the only differences between what they can do and what a full dev can do being that a dev can transfer to the main tree, and of course also that if there ever /were/ a disagreement that got to the point of "me or him", the dev would most likely win, but of course everyone knows that so in practice it doesn't tend to get to that point. However, project overlays are entirely under the control of that project, which means it's up to them what the rules are. Projects such as kde (the one I'm most familiar with in that regard, but there are others) really depend quite heavily on the work of trusted users who really do a lot of the actual grunt work in the overlay, while others are I believe gentoo-dev-only. So it ends up being a project decision. If the devs in the games project aren't comfortable with user write access, their overlay, their rules, and it won't happen. If they are, their overlay, their rules, and it will. Which is what this whole thread is about. Apparently the games project devs aren't comfortable with user access, at least not enough to make the existing user-controlled overlay a viable official project overlay, so if they want an overlay, they will need to create a new one. Perhaps at some point they'll /get/ comfortable with having trusted user access and gamerlay might tighten up access a bit so they can merge, but at this point, a new, seperate devs-only overlay seems to be what they have in mind, and as they'll be making the decisions, that's very likely what they'll get. >> The way our current portage tree is set up basically forces us into an >> all-or-nothing security model for commit access - we don't have layers >> of integration testing to protect users from errors or abuses. >> >> Proxy maintainership is one way around this. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
