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
