Rich Freeman wrote: > >> This is not a great way to invite more users to participate. If you > >> intend to make the game overlay and team a developer-only thing you > >> are doing a great work. > > > > 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.
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. > 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. > and arch testers have elevated privileges in bugzilla. I should have included bugzilla among mailing lists+IRC, users can indeed also have elevated privileges on IRC, but never equal to developers. It is radical exclusion and I'm reminded of it every time the #gentoo-dev channel mode catches my eye, painfully so if there's a discussion I could perhaps contribute to. Most of the time it is easy enough to say something privately to a relevant developer, but that's still very different from actual participation. > 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. I considered mentioning it but I didn't because I think it's clear to everyone that it is indeed a workaround. > I think there are many here who would love to see more non-developer > contribution. Yes, I am absolutely sure that this is the case! But even though my blanket statement was incorrect, I guess the fact that I was wrong about this even after using Gentoo fairly actively for nearly 10 years means that it is not so clear to users if they can actually contribute in easy ways, and partially hostile documentation of course doesn't help. > Suggestions are always welcome, and those willing to put in effort > to make the suggestions happen are probably even more welcome. I for one consider the portage tree and the tools around it to be Gentoo's core value so I think writes to it becoming more accessible is the number one suggestion. > Moving to git certainly won't hurt, but that won't automatically > change anything either. I disagree there - it automatically changes what is effortlessly doable thanks to existence of helpful tooling and it also changes intuitive expectations as far as workflow goes. I do think that a world-writable Gerrit instance in front of a portage git tree will actually suffice to dramatically increase user participation - and of course bring significant developer review workload along with it! :) Everyone knows I'd like to see that happen, and I know that it is being worked on - I'm not in a hurry, but even so you're right that it still does not change the fact that only developers can submit commits from Gerrit into portage. As I already wrote I think there are both significant pros and cons to the developer-only approach, and because of how powerful and flexible Gentoo is there's no easy solution. As a case in point, TomWij made a mistake for an arch he rarely if ever uses. Gentoo is complex and also wonderful, and that means that contributing in the general case is not very easy. Simplifying the common case of x86/amd64 revbump (a world-writable Gerrit) will lead to more contribution, but what about the corner cases - it's impossible to know if I've actually tested my new ebuild on hppa if I just copypaste the old ebuild. I shouldn't need to communicate my testing out-of-band in a bugzilla or whatever and a thought I just had is that KEYWORDS may perhaps need higher temporal resolution than existing once per file.ebuild.. OTOH I don't think it's a good idea to require post-processing of the entire gentoo-x86 worktree to make it usable for portage. Tricky. //Peter
