| 1 |
Well, |
| 2 |
I think a lot of what I've been thinking recently has already been said |
| 3 |
by Daniel. I'm actually in the middle of being inducted and I'm just |
| 4 |
concerned that I'm going to get extra responsibility without any real |
| 5 |
positive aspects for me. I don't really *want* access to check into |
| 6 |
portage, I don't know what I'm doing (yet) and I'm not certain I can |
| 7 |
invest the time to learn all the precise policy to ensure I don't make a |
| 8 |
mistake, or worse put up with the stress of worrying I'll do it wrong |
| 9 |
and affect the entire gentoo vmware-using userbase. |
| 10 |
What I tend to do is make ebuilds for things that I want to try out or |
| 11 |
things that are broken, and I'd really like to just keep on doing that, |
| 12 |
but have it more accessible to the rest of the userbase. |
| 13 |
I think the idea of a proxy is a good one. I don't know about a whole |
| 14 |
user repository though, because as Ciaran pointed out, one bad apple and |
| 15 |
everybody gets rooted. No one would trust it, so it wouldn't be worth |
| 16 |
it anyway. |
| 17 |
|
| 18 |
* It'd be a good idea to have a larger group of devs not dedicated to a |
| 19 |
particular project, but who can take user submitted ebuilds, vet them |
| 20 |
for nastiness, and submit them. They'll be officially contributed |
| 21 |
ebuilds, they won't get updated until either a dev offers to take them |
| 22 |
on, or the community offers to fix them. |
| 23 |
|
| 24 |
* I think also a larger number of bugzilla scouring devs could push |
| 25 |
through well tested (lots of positive feedback, no negative feedback) |
| 26 |
patches that the maintainers for whatever reason (aren't there, forgot |
| 27 |
about it, don't have the time) just aren't putting through. That would |
| 28 |
require bending the maintainer etiquette a bit though. |
| 29 |
|
| 30 |
* I guess a *quick* concise policy guide would help. Separate from the |
| 31 |
ebuild guide which is trying to teach you *how* to write ebuilds, this |
| 32 |
policy guide would tell you what MUST and MUST NOT happen in a good |
| 33 |
Quality Assured ebuild. For instance, if the various and sundry checks |
| 34 |
in repoman could be extracted for people to run over their own overlays |
| 35 |
without all the main portage cvs machinery in there, it would help them |
| 36 |
get *much* better trained in what makes a good ebuild and what doesn't. |
| 37 |
If it can already do that, then it needs better documentation. |
| 38 |
|
| 39 |
* Finally the mentoring scheme could perhaps be more streamlined. So |
| 40 |
rather than having an all-or-nothing gentoo developer membership. Those |
| 41 |
developers being mentored have a repoman-like interface that works |
| 42 |
almost exactly the same way, but instead of putting directly into0 the |
| 43 |
tree, it would submit to a holding area where an experienced ebuild |
| 44 |
writer can either send it back to them with comments, or put a tick next |
| 45 |
to it and pass it into the main overlay. This then would allow people |
| 46 |
to work up to becoming a full dev, and take their time over it. It |
| 47 |
would also offer a kind of buffer area for people who just want to help |
| 48 |
for a few months, their privilege levels don't have to rise too high. |
| 49 |
|
| 50 |
So these are some ideas. Sorry, I was trying to get these out |
| 51 |
concisely but tripped on my tongue somewhere along the way, hope they |
| 52 |
help generate some ideas... |
| 53 |
Mike 5:) |
| 54 |
-- |
| 55 |
gentoo-dev@g.o mailing list |
Archives