Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted

[Mart Raudsepp]

On Wed, 2009-05-13 at 20:47 -0500, Jeremy Olexa wrote:
> Mart Raudsepp wrote:
> > Hello,

Hey,

> > I have had this project in my mind for a while, so it's about time to
> > get it out there, as to see if feedback finds it a good one - and if
> > that is so, if there are people who want to make it happen.
> <snip>
>
> Hmm, I wonder what the point is when there is 400 maintainer-needed bugs
> open..

The point is making popular packages available in the _portage tree_.
When widely used popular packages end up in maintainer-needed, they tend
to be relatively quickly picked up by other teams or developers.
maintainer-wanted hopes for the same, that they will tend to be picked
up by others. Most of the 400 packages affected by maintainer-needed
bugs are probably as such because close to no-one cares about them, and
caring by the project proposed here doesn't get us any closer to world
domination(tm) - we'd just have more packages of quality, except no-one
uses those packages. We already have a set of people, of which you
Jeremy seem to be participating in, that takes care of maintainer-needed
bugs that have user patches available, hence the packages people
actually care about are eventually taken care of as well as I
understand. Maybe that project should formalize themselves as well. Or
we can add that set of tasks to this one.

That said, my initial idea months ago was related to the
maintainer-needed alias, taking care of the packages of greater interest
marked maintainer-needed and introducing new ones that are encouraged to
be taken over. But by now I don't think mixing those together is a good
idea. The community maintained packages idea from another e-mail was
quite good to not mix with maintainer-wanted either (the point about
making sure new package requests and bugs against in-tree
maintainer-wanted packages don't get mixed), except I think that naming
doesn't so strongly express that other dedicated maintainers are
desired.


> I think a maintainer-wanted team won't accomplish much because it just
> uses more developer time from a pool of "not enough time" that exists
> already.

Volunteer manpower doesn't work quite like that.
Volunteers have as much time as they make for this as a hobby of
interest. Developer A is interested in keeping old crufty stuff dropped
to maintainer-needed in quality condition as they like that sort of
thing, while developer B doesn't and he likes the satisfaction of making
much desired new packages available to the wider user base instead. If
you don't have a project encouraging that, developer B can end up just
not taking more time for Gentoo and does more of other stuff instead,
lets say gardening or watching random TV.

Because we don't provide monetary motivation to take care of exotic and
outdated packages to get that out of the way shouldn't block people
motivated in providing popular packages that would be used by a larger
set of the user base and contribute to the popularity of Gentoo.

> If people are a) too lazy to contribute to sunrise, b) don't
> know about sunrise, or c) don't know enough about ebuilds to contribute
> to sunrise, then we need to fix[1] that.

Sure, the sunrise project can do all of that. That doesn't make the
packages available in the official tree. The maintainer-wanted project
however can tap into the work done by sunrise when a popular package is
to be added to the tree that already exists in Sunrise. If certain
interested in the package users are contributing to Sunrise for that
package, they could hopefully be turned into proxy maintainers in the
official tree version and perhaps even eventually become developers as
well when they have interest in a larger set of packages. If they have
been maintaining a lot of different package in Sunrise before that, they
seem to be a good candidate in joining the maintainer-wanted team too
then, as they seem to be motivated by the kind of work they do, as same
work was done in an overlay by him/her before.
Close collaboration with Sunrise is good, that is. So the end outcome
would be that the packages that are used by many people are available in
the official tree.

> I don't see any reason to create a team that duplicates the sunrise
> work. Keep in mind, I am against pretty much any overlay, I think work
> should be kept in the main tree. But, for ebuild maintenance with
> limited developer time, sunrise just makes sense(tm).

Developer time is not so strictly limited. The motivation to spend more
time on Gentoo instead of other daily non-work not-so productive
activities might be limited. Yes, we also have the small set of
developers that do a very large chunk of the work - they are limited in
time indeed because they already are so motivated to use so much time
for Gentoo.
I am a strong believer in the correlation of motivation and time spent
on volunteer hobby work as you can see.

> Some other possible directions include:
> 1) maintainer-needed team - Where a group maintains the set of 761
> m-needed packages.

Sounds reasonable for achieving different goals. The popular packages of
these 761 could be taken over by the maintainer-wanted team as well when
that team is interested, while the maintainer-needed team would make
sure those remaining 700 packages don't block stabilization of newer
system packages, etc

> 2) proxy maint project[2] - Where a group helps users commit to the main
> tree, very similar to the sunrise project. Very similar to this proposal
> but better conserves our developer time.

Maybe adding this blurb to the proposal text:
When the bug request for the package has contributors for the package,
it is encouraged to draft them as a proxy maintainer(s), with the
maintainer-wanted team being the committers and ensuring quality.

> -Jeremy
>
> [1]: http://dev.gentoo.org/~darkside/sunrise_proposal.txt
> http://dev.gentoo.org/~darkside/sunrise_status.txt
> [2]: http://dev.gentoo.org/~antarus/projects/proxy-maint/

-- 
Mart Raudsepp
Gentoo Developer
Mail: leio@g.o
Weblog: http://planet.gentoo.org/developers/leio