On Thu, Mar 18, 2010 at 06:29:56PM +0200, Markos Chandras wrote:
> Dear fellow developers,
>
> A new project is about to start so I am requesting your feedback
>
> The primary goal of the Proxy Maintainers[1] project is to create and maintain
> relationships between developers and users in order to ensure packages in the
> Gentoo tree stay up to date. This involves a few main tasks:
>
>
> [...]
>
> 1) Should we use a new overlay? A new branch on sunrise? or work ebuilds in
> Gentoo bugzilla?I think the latter is the best

IMO, the best route would be to start with-in Gentoo Bugs, then slowly
move each contributor to a proxy-maintainer overlay.

This overlay would not have a review process for ebuilds, meaning that every
contributor that has passed the first stage (by submitting a few ebuilds in
bugzilla) will be granted access.

that way users will:

* get experience on actually committing stuff to a tree
* learn how to use tools like repoman and git (think of the future )

it will also be better for us. moving packages from the overlay to tree
will be simpler, also tracking versions and package status will be
easier.

> 2) I think an email alias is not needed We can "monitor" maintainer-wanted/-
> needed alias if needed. What do you think?

If we go with the new overlay, I think we'll need an alias where the
users can ask for help and talk about their packages.

> 3) Maybe a new KEYWORD needs to be added on bugzilla so ppl get informed that
> the specific bug is already taking by another developer and that somebody is
> working on it. So marking a bug with a keyword e.g. "PROXY" might be useful.

Thats not a bad idea.
Another solution would be to assign the bugs to proxy-maintainers@g.o.

--
Alex Alexander :: wired
Gentoo Developer
www.linuxized.com

On 03/18/2010 04:34 PM, Ben de Groot wrote:

Recruitment being the bottleneck that it is (with candidates
waiting many months), it is good to have another option
for people who want to contribute.


If we do have a list of people waiting to get in, could we maybe publish
this list somewhere, or instruct these people to look for
maintainer-wanted bugs and offer their services as proxy-maintainers?
Can we have some way of communicating that one of these almost-devs has
written some ebuilds so that devs can work with them to get them committed?


This would get them a head-start and will give them VERY practical
instruction. For the devs that work with them they'll know that they're
working with somebody with a long-term interest. I'm not sure that we
want a policy that states that when the recruits become devs that they
will maintain these packages long-term, but it would be nice if they did so.


Perhaps the devs could also provide feedback to the recruiters on the
recruit's strong/weak points so that they could work on these. (NOTE -
I'm not suggesting marking people for exclusion here - if somebody is
fairly raw we want to work with them, but it doesn't hurt for the
recruiters to know about that up-front.)


I realized that some of these ideas are still half-baked, but I'm
wondering if there isn't an opportunity here.


Rich