Re: [gentoo-dev] Making the developer community more open

[Mike Auty <mike.auty@gmail.com>]

Well,
	I think a lot of what I've been thinking recently has already been said 
by Daniel.  I'm actually in the middle of being inducted and I'm just 
concerned that I'm going to get extra responsibility without any real 
positive aspects for me.  I don't really *want* access to check into 
portage, I don't know what I'm doing (yet) and I'm not certain I can 
invest the time to learn all the precise policy to ensure I don't make a 
mistake, or worse put up with the stress of worrying I'll do it wrong 
and affect the entire gentoo vmware-using userbase.
	What I tend to do is make ebuilds for things that I want to try out or 
things that are broken, and I'd really like to just keep on doing that, 
but have it more accessible to the rest of the userbase.
	I think the idea of a proxy is a good one.  I don't know about a whole 
user repository though, because as Ciaran pointed out, one bad apple and 
everybody gets rooted.  No one would trust it, so it wouldn't be worth 
it anyway.

* It'd be a good idea to have a larger group of devs not dedicated to a 
particular project, but who can take user submitted ebuilds, vet them 
for nastiness, and submit them.  They'll be officially contributed 
ebuilds, they won't get updated until either a dev offers to take them 
on, or the community offers to fix them.

* I think also a larger number of bugzilla scouring devs could push 
through well tested (lots of positive feedback, no negative feedback) 
patches that the maintainers for whatever reason (aren't there, forgot 
about it, don't have the time) just aren't putting through.  That would 
require bending the maintainer etiquette a bit though.

* I guess a *quick* concise policy guide would help.  Separate from the 
ebuild guide which is trying to teach you *how* to write ebuilds, this 
policy guide would tell you what MUST and MUST NOT happen in a good 
Quality Assured ebuild.  For instance, if the various and sundry checks 
in repoman could be extracted for people to run over their own overlays 
without all the main portage cvs machinery in there, it would help them 
get *much* better trained in what makes a good ebuild and what doesn't. 
    If it can already do that, then it needs better documentation.

* Finally the mentoring scheme could perhaps be more streamlined.  So 
rather than having an all-or-nothing gentoo developer membership.  Those 
developers being mentored have a repoman-like interface that works 
almost exactly the same way, but instead of putting directly into0 the 
tree, it would submit to a holding area where an experienced ebuild 
writer can either send it back to them with comments, or put a tick next 
to it and pass it into the main overlay.  This then would allow people 
to work up to becoming a full dev, and take their time over it.  It 
would also offer a kind of buffer area for people who just want to help 
for a few months, their privilege levels don't have to rise too high.

	So these are some ideas.  Sorry, I was trying to get these out 
concisely but tripped on my tongue somewhere along the way, hope they 
help generate some ideas...
	Mike  5:)
-- 
gentoo-dev@gentoo.org mailing list