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

[Pacho Ramos]

El jue, 14-05-2009 a las 03:32 +0300, Mart Raudsepp escribió:
> Hello,
>
> 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.
> It is worded as a hypothetical project description for the purpose of
> the text perhaps being a draft for the projects official description. So
> in the following text instead of terms like "this project would be" I'm
> purposely using terms like "this project is", as while writing it, it
> got quickly very awkward writing "would be" and such all the time.
> Please take it still as a proposal to be judged, commented, improved,
> etc etc. And well, do that commenting and improving and volunteering ;)
>
>
> Project maintainer-wanted
> =========================
>
> Abstract:
> There are currently quite some package requests (over 3000) languishing
> on bugzilla waiting for a developer or team to get interested and
> package it in the official gentoo-x86 portage tree. However in quite
> some cases that might not happen for quite a while even with very
> popular packages desired by users. The purpose of the maintainer-wanted
> project is to get as many of such packages to the official tree as
> possible as a stopgap solution.
>
>
>
> Details/implementation:
>
> The maintainer-wanted team is actively looking for popular packages in
> bugzilla that have been waiting for packaging in the official
> "gentoo-x86" tree for a while, and package and maintain as many of them
> as the project teams manpower allows without sacrificing quality.
>
> To decide which libraries/application get packaged in the official tree
> by the project, various factors can be considers by the team. These can
> include metrics such as:
> * bugzilla vote count amongst open maintainer-wanted packages
> * recent general useful activity on the packages bugzilla entry
> * past and present user community activity in providing ebuild
> improvements, version bumps and fixes in the packages bugzilla
> maintainer-wanted bug entry
> * ease of the packaging thanks to active user contributions or
> consistently good upstream packaging making the workload of the
> maintainer-team not grow much
> * team members interest and personal qualification in the type of the
> package and its packaging methods
> * ...
>
>
> maintainer-wanted maintained packages are seen as a stopgap solution. As
> such it is desired that eventually a team or developer takes over
> maintenance to provide the packages dedicated care and free up the
> maintainer-wanted team to make available more desired packages that do
> not yet have a dedicated maintainer. To achieve that, various methods
> are pursued:
>
> * Other teams and developers are encouraged to take over maintenance.
> This includes proxy maintenance when for example a user is found to
> consistently and with good quality help out the maintainer-wanted team
> in providing fixes, improvements and bumps to an in-tree
> maintainer-wanted maintained package. Taking over maintenance is as easy
> as for maintainer-needed packages, however a notification to and
> acknowledgment from a maintainer-wanted team member is appreciated.
>
> * Lists of maintainer-wanted packages are generated, sorted by category
> of interest. Developers and dedicated package teams are encouraged to
> find packages of interest from these lists and take over maintenance.
>
> * Simply the easier availability (and the resulting exposure) of a
> package in the official tree (as opposed to an unreviewed, yet possibly
> high quality, ebuild attached to bugzilla, which has thousands of such
> entries) could catch the interest of another team or developer and they
> are encouraged to take over maintenance when they have the capacity
> (manpower/time etc)
>
>
> In other ways the maintainer-wanted team is not significantly different
> to other package maintaining teams:
> * The project is responsible for their maintained packages. Quality is
> not sacrificed; bugs on in-tree packages get acted upon, etc. As such it
> is likely desired to have a different alias than the default one for new
> packages (or a different good means of differentiating), as to not have
> bugs against already in-tree packages get lost amongst the hundreds or
> thousands of packages still waiting to get into the official package
> tree.
> * In-tree maintainer-wanted packages are also tried to be kept up to
> date in regards to new stable upstream versions. Users are encouraged to
> file bump requests on bugzilla even as 1-day requests due to the
> diversity of packages maintained by the project and therefore too many
> different places and notification mechanisms to manually check and
> monitor for the team (bugzilla version bump requests solve the
> diversity); at least until no mechanisms exist for automatic checking of
> bumps, which could get implemented in the future.
>
>
> The maintainer-team project hopes to make previously directly
> unavailable popular packages of quality easily available to the user
> base until other projects and developers are able to take over.
>
>
> ----
>
> Discuss! :)

Maybe other option would be to use sunrise project for that:
1. Bugs related with new package additions could be automatically
assigned to something like sunrise@g.o
2. sunrise@g.o would be a group that would try to get these apps
in sunrise overlay as soon as possible. Also, as more people would be in
that "sunrise" herd, hopefully, updates, version bumps and some bug
fixes would be done faster, as the same people could handle more than
one app. For example, if I were a sunrise member then, if I had a bit of
free time, I could check bug list and try to fix as much bugs I were
able to. Also, me, as a member of that herd, would get mails from
bugzilla with new bugs related to that apps.
3. People, could join to sunrise herd for helping with this task (of
course after aproval of current sunrise leaders)

Regards