* [gentoo-dev] RFC: Project proposal -- maintainer-wanted
@ 2009-05-14 0:32 Mart Raudsepp
2009-05-14 1:24 ` Gokdeniz Karadag
` (7 more replies)
0 siblings, 8 replies; 36+ messages in thread
From: Mart Raudsepp @ 2009-05-14 0:32 UTC (permalink / raw
To: gentoo devs
[-- Attachment #1: Type: text/plain, Size: 5154 bytes --]
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! :)
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 0:32 [gentoo-dev] RFC: Project proposal -- maintainer-wanted Mart Raudsepp
@ 2009-05-14 1:24 ` Gokdeniz Karadag
2009-05-14 1:27 ` AllenJB
` (6 subsequent siblings)
7 siblings, 0 replies; 36+ messages in thread
From: Gokdeniz Karadag @ 2009-05-14 1:24 UTC (permalink / raw
To: gentoo-dev
Hi,
The project would be very beneficial if it gets live.
But from the very start its name should be unambigious,
I would suggest "community-maintained" as the name, including both the
developer community and user community.
And also, the project should advise the sunrise overlay for packages with many
contributions from users, if the package cannot be in the main tree for one
reason or another.
Mart Raudsepp demis ki::
> Hello,
...
> Project maintainer-wanted
> =========================
> ...
--
Gokdeniz Karadag
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 0:32 [gentoo-dev] RFC: Project proposal -- maintainer-wanted Mart Raudsepp
2009-05-14 1:24 ` Gokdeniz Karadag
@ 2009-05-14 1:27 ` AllenJB
2009-05-14 14:44 ` Richard Freeman
2009-05-14 1:47 ` [gentoo-dev] " Jeremy Olexa
` (5 subsequent siblings)
7 siblings, 1 reply; 36+ messages in thread
From: AllenJB @ 2009-05-14 1:27 UTC (permalink / raw
To: gentoo-dev
Mart Raudsepp wrote:
> 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.
>
> <SNIP>
>
> ----
>
> Discuss! :)
>
> Mart Raudsepp
> Gentoo Developer
> Mail: leio@gentoo.org
> Weblog: http://planet.gentoo.org/developers/leio
So, to solve the problem of lack of manpower / interest causing packages
not to be added to the tree, Gentoo will create a dedicated project to
shove as many of these packages into the tree as possible?
In my opinion, you've failed to solve the real problem:
Where is the manpower and interest for this project going to come from?
All that's going to happen is Gentoo will have many many buggy and out
of date packages in the MAIN TREE. Exactly where they shouldn't be. You
claim quality won't be sacrificed, but I simply can't see this without
any attempt to solve the manpower issues first.
Isn't the purpose of this project already somewhat covered by Sunrise?
If developers are interested in shoving packages without a maintainer
into a tree (while not retaining quite the same level of responsibility
for them), can't they already do it there? A dedicated overlay which is
already monitored, but packages are not guaranteed to be as highly
maintained as those in the main tree (from my point of view of what
Sunrise is)
Proxy maintenance is already available via going directly to interested
developers / projects or via the Sunrise overlay.
As a user I would not like to see Gentoo pursue this policy. It's going
to create a situation where I can't trust that the packages in the main
tree are maintained to the level I expect.
To my knowledge, a list of maintainer-wanted bugs can already be easily
generated using Bugzilla's search feature. While some sort of more
organized format may possibly increase uptake of maintainer-wanted
packages, I'm dubious as to how much compared to the amount of effort
required to create it.
Summary: I believe that this project will create problems, not solve them.
Gentoo should be looking at ways to encourage user contributions to
Sunrise and proxy maintainership. In my opinion this would include more
publicizing of these avenues - for example, bring back the newsletter
and start features on Gentoo projects (who they are, what they do,
roadmap, help needed - basically the same as the status reports that
occasionally go to -devel), new developer profiles (again, instead of
these only going to -devel) and proxy maintainership / Sunrise (latest
additions, moves to main tree).
While the existing docs are quite good, perhaps look at how the
documentation on creating packages can be improved (perhaps start with a
basic "how to" on creating a simple ebuild, putting it in a local
overlay and manifesting it).
(Side note: I've started a very small project of putting up the Project
Status summaries on to the wiki[1], linked from the forums[4] and a
blog[2] post on Planet Larry[3] - it's not much, but it's a start that I
hope to build on in the future)
[1] http://en.gentoo-wiki.com/wiki/Projects_Status
[2] http://allenjb.me.uk
[3] http://planet.larrythecow.org
[4] http://forums.gentoo.org/viewtopic-t-763205.html
I think Gentoo could be doing more to reach out to users who may wish to
contribute rather than just waiting for them to come to them. While many
probably do read Planet Gentoo and some will sign up to -devel if they
are so inclined, I don't think these methods are as good as actively
reaching out to users on the forums and newsletter.
With regards to the forums, I realize many developer choose not to spend
time there because of their lack of free time, but is there anything
that could be done to improve this situation? Perhaps creating a
dedicated forum for package development (and splitting up "Portage &
Programming" generally - I personally think it's too much of a
catch-all). What about a forum setup that better resembles the project
setup so that individual projects can more easily find queries that are
likely to affect them?
AllenJB
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 0:32 [gentoo-dev] RFC: Project proposal -- maintainer-wanted Mart Raudsepp
2009-05-14 1:24 ` Gokdeniz Karadag
2009-05-14 1:27 ` AllenJB
@ 2009-05-14 1:47 ` Jeremy Olexa
2009-05-14 5:41 ` [gentoo-dev] " Duncan
` (2 more replies)
2009-05-14 6:53 ` Pacho Ramos
` (4 subsequent siblings)
7 siblings, 3 replies; 36+ messages in thread
From: Jeremy Olexa @ 2009-05-14 1:47 UTC (permalink / raw
To: gentoo-dev
Mart Raudsepp wrote:
> 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.
<snip>
Hmm, I wonder what the point is when there is 400 maintainer-needed bugs
open..
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. 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.
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).
Some other possible directions include:
1) maintainer-needed team - Where a group maintains the set of 761
m-needed packages.
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.
-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/
^ permalink raw reply [flat|nested] 36+ messages in thread
* [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
2009-05-14 1:47 ` [gentoo-dev] " Jeremy Olexa
@ 2009-05-14 5:41 ` Duncan
2009-05-14 5:54 ` Patrick Lauer
2009-05-14 9:09 ` Christian Faulhammer
2009-05-14 10:12 ` [gentoo-dev] " Mart Raudsepp
2 siblings, 1 reply; 36+ messages in thread
From: Duncan @ 2009-05-14 5:41 UTC (permalink / raw
To: gentoo-dev
Jeremy Olexa <darkside@gentoo.org> posted 4A0B783C.2000501@gentoo.org,
excerpted below, on Wed, 13 May 2009 20:47:40 -0500:
> 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).
This was my first reaction as well. How is this different than sunrise?
If it's not duplicative, map out the difference and the proposed
relationship of apparently duplicative projects.
Maybe you just want Sunrise in the main tree instead of as a dedicated,
supervised overlay. There were people with VERY strong feelings against
Sunrise, to the point I believe at least one dev opposing it resigned
over it and other boosting it were disciplined. Are you ready to take on
that sort of opposition to get it in-tree? Maybe it's time to have that
debate.
> Some other possible directions include: 1) maintainer-needed team -
> Where a group maintains the set of 761 m-needed packages.
Right. The new proposal needs to address this as well. Why ignore the
existing m-needed packages begging for care in the tree, just to
effectively shove a bunch more in.
> 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.
Yet another existing solution this proposal would seem to duplicate. If
it's different, map out how and how the relationship in the apparent
overlap should be managed.
If there's a place for the new project and maybe there is, the
differences from and relationship with the Sunrise and proxy-maint
projects, and the method of bringing in or justification for ignoring the
hundreds of existing m-needed packages while arguably creating more,
needs mapped out. Alternatively, bend the proposal into a status change
for one or all of the above, and call a debate on that.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
2009-05-14 5:41 ` [gentoo-dev] " Duncan
@ 2009-05-14 5:54 ` Patrick Lauer
2009-05-14 12:49 ` Alexander Færøy
0 siblings, 1 reply; 36+ messages in thread
From: Patrick Lauer @ 2009-05-14 5:54 UTC (permalink / raw
To: gentoo-dev
[Snip]
> Maybe you just want Sunrise in the main tree instead of as a dedicated,
> supervised overlay. There were people with VERY strong feelings against
> Sunrise, to the point I believe at least one dev opposing it resigned
> over it
Yes, one did. Some people just need a good excuse to leave :)
> and other boosting it were disciplined.
Not that I remember.
> Are you ready to take on
> that sort of opposition to get it in-tree? Maybe it's time to have that
> debate.
Oh be quiet. Sunrise is a quite convenient testing ground, and I've borrowed
quite a few ebuilds from there for the main tree. I haven't seen any issues in
the last few months, those opposed seem to have finally accepted that users
collaborating is not a stupid idea. And you get a nice recruiting area for
free ...
[Snip]
> If there's a place for the new project and maybe there is, the
> differences from and relationship with the Sunrise and proxy-maint
> projects, and the method of bringing in or justification for ignoring the
> hundreds of existing m-needed packages while arguably creating more,
> needs mapped out. Alternatively, bend the proposal into a status change
> for one or all of the above, and call a debate on that.
I'd be for a discussion of "all of the above" since they are quite strongly
linked.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 0:32 [gentoo-dev] RFC: Project proposal -- maintainer-wanted Mart Raudsepp
` (2 preceding siblings ...)
2009-05-14 1:47 ` [gentoo-dev] " Jeremy Olexa
@ 2009-05-14 6:53 ` Pacho Ramos
2009-05-14 11:02 ` Markos Chandras
` (3 subsequent siblings)
7 siblings, 0 replies; 36+ messages in thread
From: Pacho Ramos @ 2009-05-14 6:53 UTC (permalink / raw
To: gentoo-dev
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@gentoo.org
2. sunrise@gentoo.org 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
^ permalink raw reply [flat|nested] 36+ messages in thread
* [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
2009-05-14 1:47 ` [gentoo-dev] " Jeremy Olexa
2009-05-14 5:41 ` [gentoo-dev] " Duncan
@ 2009-05-14 9:09 ` Christian Faulhammer
2009-05-14 10:12 ` [gentoo-dev] " Mart Raudsepp
2 siblings, 0 replies; 36+ messages in thread
From: Christian Faulhammer @ 2009-05-14 9:09 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 410 bytes --]
Hi,
Jeremy Olexa <darkside@gentoo.org>:
> I don't see any reason to create a team that duplicates the sunrise
> work.
More power to Sunrise, yes. Sunrise is a great project, although I
don't dedicate too much time for it nowadays.
V-Li
--
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode
<URL:http://gentoo.faulhammer.org/>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 1:47 ` [gentoo-dev] " Jeremy Olexa
2009-05-14 5:41 ` [gentoo-dev] " Duncan
2009-05-14 9:09 ` Christian Faulhammer
@ 2009-05-14 10:12 ` Mart Raudsepp
2009-05-14 17:06 ` Thomas Sachau
2 siblings, 1 reply; 36+ messages in thread
From: Mart Raudsepp @ 2009-05-14 10:12 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 6194 bytes --]
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@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 0:32 [gentoo-dev] RFC: Project proposal -- maintainer-wanted Mart Raudsepp
` (3 preceding siblings ...)
2009-05-14 6:53 ` Pacho Ramos
@ 2009-05-14 11:02 ` Markos Chandras
2009-05-14 14:23 ` Mart Raudsepp
2009-05-14 18:24 ` Roy Bamford
` (2 subsequent siblings)
7 siblings, 1 reply; 36+ messages in thread
From: Markos Chandras @ 2009-05-14 11:02 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 821 bytes --]
On Thursday 14 May 2009 03:32:12 Mart Raudsepp wrote:
> Hello,
>
> I have had this project in my mind for a while, so it's about time to
>[..]
I think there is no need for this project. Developers can always browse
bugzilla and pick every 'maintainer-wanted' ebuild they like. At least this
is what I do. I am not sure how this project will make things better. In
order to push something on portage, you need to test it and use it and like
it and taking care of it. Apparently you wont push a package that you dont
give a s*** :)
So this project will do what each developer is doing individually. Am I the
only one who is searching bugzilla for maintainer-wanted packages? o_0
--
Markos Chandras (hwoarang)
Gentoo Linux Developer [KDE/Qt/Sound/Sunrise]
Web: http://hwoarang.silverarrow.org
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
2009-05-14 5:54 ` Patrick Lauer
@ 2009-05-14 12:49 ` Alexander Færøy
2009-05-14 14:13 ` Nirbheek Chauhan
0 siblings, 1 reply; 36+ messages in thread
From: Alexander Færøy @ 2009-05-14 12:49 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 243 bytes --]
On Thu, May 14, 2009 at 07:54:35AM +0200, Patrick Lauer wrote:
> Yes, one did. Some people just need a good excuse to leave :)
You lost the best laptop developer Gentoo had ever had..
--
Alexander Færøy
http://dev.exherbo.org/~ahf/
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
2009-05-14 12:49 ` Alexander Færøy
@ 2009-05-14 14:13 ` Nirbheek Chauhan
0 siblings, 0 replies; 36+ messages in thread
From: Nirbheek Chauhan @ 2009-05-14 14:13 UTC (permalink / raw
To: gentoo-dev
To potential responders to this message:
Nothing to see here, please move along.
Everytime you reply to this message, a kitten is deleted.
2009/5/14 Alexander Færøy <ahf@0x90.dk>:
> On Thu, May 14, 2009 at 07:54:35AM +0200, Patrick Lauer wrote:
>> Yes, one did. Some people just need a good excuse to leave :)
>
> You lost the best laptop developer Gentoo had ever had..
>
> --
> Alexander Færøy
> http://dev.exherbo.org/~ahf/
>
--
~Nirbheek Chauhan
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 11:02 ` Markos Chandras
@ 2009-05-14 14:23 ` Mart Raudsepp
2009-05-14 14:50 ` Richard Freeman
0 siblings, 1 reply; 36+ messages in thread
From: Mart Raudsepp @ 2009-05-14 14:23 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2986 bytes --]
On N, 2009-05-14 at 14:02 +0300, Markos Chandras wrote:
> On Thursday 14 May 2009 03:32:12 Mart Raudsepp wrote:
> > Hello,
> >
> > I have had this project in my mind for a while, so it's about time to
> >[..]
> I think there is no need for this project. Developers can always browse
> bugzilla and pick every 'maintainer-wanted' ebuild they like. At least this
> is what I do. I am not sure how this project will make things better. In
> order to push something on portage, you need to test it and use it and like
> it and taking care of it. Apparently you wont push a package that you dont
> give a s*** :)
> So this project will do what each developer is doing individually. Am I the
> only one who is searching bugzilla for maintainer-wanted packages? o_0
There are various differences with this being a project instead of
individual developers picking up a few. I think most are benefits, but
some can be perhaps viewed the opposite way as well, hence the thread :)
It is a project and hence a team, so there can be multiple developers in
the team, all sharing the workload and making sure quality and
up-to-dateness is kept. A separate e-mail alias to get bug reports to
that any of the team members can attend to, etc. Basically the typical
benefits of a team vs individuals
The packages are still kept up for grabs for individual packages.
Instead of you looking for packages of interest to maintain from
bugzilla maintainer-wanted ones, you have an additional place to look at
- one that would be more easily browseable and categorized. If you find
a package of interest you would like to maintain out of that list, you
simply take over maintenance from maintainer-wanted team, as finding a
dedicated is exactly the eventual goal and that gets accomplished then.
Meanwhile users have the package available earlier.
Liking and using the package yourself shouldn't be a prerequisite for a
package getting to be in-tree by the maintainer-wanted team. It is hoped
that for them the driving factor is making popular packages available to
a larger user base that want to use it themselves, so that popular
applications that do not have any existing developers at the time
finding deep interest in it will not mean indefinite languishing in
bugzilla and not being easily available for users (while it probably is
for Fedora or Debian or whatever).
I'm quite sure we have developers motivated by that around. For example
when I discussed this with Samuli a few months ago, I believe he
basically said to already do work like this, except making desktop-misc
the dumping ground, loosing the benefits that a separate project and
alias would give related to both implied (from the maintaining herd name
and knowledge of its purpose) and active seeking (through package lists,
etc) for dedicated maintainers.
--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 1:27 ` AllenJB
@ 2009-05-14 14:44 ` Richard Freeman
2009-05-15 7:43 ` Thilo Bangert
0 siblings, 1 reply; 36+ messages in thread
From: Richard Freeman @ 2009-05-14 14:44 UTC (permalink / raw
To: gentoo-dev
AllenJB wrote:
>
> All that's going to happen is Gentoo will have many many buggy and out
> of date packages in the MAIN TREE. Exactly where they shouldn't be. You
> claim quality won't be sacrificed, but I simply can't see this without
> any attempt to solve the manpower issues first.
>
> Isn't the purpose of this project already somewhat covered by Sunrise?
I have to agree with your points. We need to have quality standards for
packages. Currently we have a couple of tiers:
1. Main tree - every ebuild has an official maintainer and gets prompt
security updates/etc. New features might get a little more stale, but
you aren't going to be running at risk if you only use the main tree and
routinely emerge -u world. If a package falls behind on security it
gets masked and booted.
2. Overlays - you're on your own and at the general mercy of the
overlay maintainer.
3. Sunrise (just a special case of an overlay) - somewhere in-between.
Again, you have to opt-in.
I think that we still need to have defined levels of quality, so if we
start putting unmaintained stuff in the main tree then we absolutely
need to preserve a mechanism for users to indicate what level of quality
they desire. Users running a typical install shouldn't inadvertently
have dependencies pulled in which aren't fully controlled for security
issues.
Could something like sunrise be integrated into the main tree? Sure.
However, there would need to be lots of rules and QA checks like
non-sunrise packages not depending on sunrise packages and the sunrise
packages are somehow clearly marked. Maybe even an ACCEPT_QUALITY =
"good-luck-with-that" setting or something like that in make.conf. We
might also need tiered levels of security in cvs. I'm not convinced
that in the end it will be any better than just having those who are
interested add an overlay to their tree.
Maybe a better option would be a way to make overlays more seamless.
Additionally we could have rating categories for overlays like "security
responsiveness," "currency with upstream," etc. The gentoo project
would ask overlays to declare their policies as a condition of being
accessible via the seamless interface, and would drop overlays if they
don't follow their policies. It would still be easy for users to pick
non-standard overlays but it would be clear that they are venturing off
on their own if they do this (just as is the case with layman today).
Sure, I'd love to see an extra 1000 supported packages in portage, but
the key is "supported", not just shoveled-in.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 14:23 ` Mart Raudsepp
@ 2009-05-14 14:50 ` Richard Freeman
2009-05-19 23:54 ` Mart Raudsepp
0 siblings, 1 reply; 36+ messages in thread
From: Richard Freeman @ 2009-05-14 14:50 UTC (permalink / raw
To: gentoo-dev
Mart Raudsepp wrote:
>
> Liking and using the package yourself shouldn't be a prerequisite for a
> package getting to be in-tree by the maintainer-wanted team.
How about actually maintaining the package?
For example, user contributes ebuild for foo-1.0. I don't use it or
like it, but I go ahead and throw it into portage. User logs bug that
foo-1.0 wipes out random files from time to time. Nobody looks at said
bug since nobody owns foo, and bug starts getting 3000 "me-too!"
comments. Some charitable developer takes a look and the problem isn't
obvious and offers to just mask the package. Now 3000 people running
foo are upset for it being de-supported (when it wasn't supported in the
first place).
Wouldn't it make more sense for people who like the foo-1.0 ebuild to
just stick it in their own ebuild or an overlay and be on their own
(since they're really on their own either way)? Or to move it to
sunrise or some other place where it might actually get some level of
support?
If Gentoo is going to distribute an ebuild Gentoo should
Do-It-Right(TM). Why put our name on something we don't really want to
care for?
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 10:12 ` [gentoo-dev] " Mart Raudsepp
@ 2009-05-14 17:06 ` Thomas Sachau
0 siblings, 0 replies; 36+ messages in thread
From: Thomas Sachau @ 2009-05-14 17:06 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 4293 bytes --]
Mart Raudsepp schrieb:
>> 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 think, you overrate the possible additional free time that developers are able and willing to
contribute to Gentoo for such a project.
If a dev is intersted in a package, he can create an ebuild, add it to the main tree and maintain it
there.
If a dev would like to add a popular package, also not being personally interested, he can still do
it, nothing prevents him from that.
But this does not happen and i think, there is a simple reason: The number of active developers with
access to the main tree is limited and the amount of work they can do is it too. In the end, this
project would create some or even many packages, that end as m-needed because the team is not
willing or able to maintain the amount of ebuilds they initially added.
If users are interested in a package and willing to create an ebuild and maintain it, they can add
it to the sunrise overlay. If they do continual good work, they can even become developers
themselves and move some apps to the main tree (like i did). If they dont continue the maintainence,
the ebuild will stay in sunrise as a base for everyone interested without polluting the main tree.
Based on this, i would suggest another basic idea (details can be discussed, if accepted):
-Make the sunrise overlay more known on different places like front page, blogs, forum etc
-Based on some checks (good QA, maintained, fixed reported problems or whatever), add good ebuilds
to the main tree with some restrictions (maybe some additional var, only unstable keywords or
similar). If there are no complains and bugs get fixed (either some dev or the maintainer (user)
does it), it will stay there, if not, it gets removed from the tree again and moved back to the
sunrise overlay.
Whith this, users would get a central place to start with reading, contributing, learning and proxy
maintaining their ebuilds, would be able to get their work to some audience (either those adding
sunrise overlay or with good work even the main tree), could learn enough to become developers with
main tree access themselves. And if they leave their work alone, it just gets moved from the main
tree back to the sunrise overlay and so cannot harm Gentoo, the security team or anyone else for a
longer time.
Just for clarification: Those contributors would still only commit to a branch not accessable via
layman nor does it automaticly write to the main tree. These contributions then get currently moved
to the reviewed tree (which is what users get via layman) after some sunrise dev did review the
commit. In this proposal, the move to the main tree and any update would go the same way, so no
direct access to the main tree by (user) contributors until they got recruited as ebuild deveopers.
With this proposal, we could recruite new people to work on things they are intersted in, so it
should be relatively easy to get popular packages in the main tree, while not using some (probably
not existing) additional dev-time.
--
Thomas Sachau
Gentoo Linux Developer
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 315 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 0:32 [gentoo-dev] RFC: Project proposal -- maintainer-wanted Mart Raudsepp
` (4 preceding siblings ...)
2009-05-14 11:02 ` Markos Chandras
@ 2009-05-14 18:24 ` Roy Bamford
2009-05-14 18:48 ` Thomas Sachau
2009-05-19 23:35 ` Mart Raudsepp
2009-05-17 18:08 ` [gentoo-dev] " Ryan Hill
2009-05-28 7:55 ` [gentoo-dev] " Peter Volkov
7 siblings, 2 replies; 36+ messages in thread
From: Roy Bamford @ 2009-05-14 18:24 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 2009.05.14 01:32, Mart Raudsepp wrote:
> Hello,
>
[snip]
> 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.
>
[snip]
>
> Discuss! :)
>
> Mart Raudsepp
> Gentoo Developer
> Mail: leio@gentoo.org
> Weblog: http://planet.gentoo.org/developers/leio
>
Mart,
I'm against for many of the reasons AllanJB outlined. There is no point
in adding more unmaintained packages to the tree. Over time, the
average quality of the tree will suffer.
We could use user contributed ebuilds attached to bugs as a way to
bring Sunrise to the contributors attention just by posting a comment
to the bug. If the contributor follows up, we get another user
maintained ebuild in Sunrise, which is good, as the current developers
don't have to do all the work. We already know some Sunrise
contributors become developers so perhaps we can use this as a way to
attract more contributors (both users and developers).
Its probably a bad idea to send all the bugspam at the same time,
Sunrise might be overwhelmed, which would be bad for Sunrise and user
contributors who would feel let down
- --
Regards,
Roy Bamford
(NeddySeagoon) a member of
gentoo-ops
forum-mods
treecleaners
trustees
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
iEYEARECAAYFAkoMYdYACgkQTE4/y7nJvav1hgCfULFWGyBpvXC5dy5KrekYYM80
QhIAnjM0GQQQKuzkf17Oj56RH7Z1X5cl
=wK1Z
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 18:24 ` Roy Bamford
@ 2009-05-14 18:48 ` Thomas Sachau
2009-05-17 9:00 ` Tobias Scherbaum
2009-05-19 23:35 ` Mart Raudsepp
1 sibling, 1 reply; 36+ messages in thread
From: Thomas Sachau @ 2009-05-14 18:48 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 983 bytes --]
Roy Bamford schrieb:
> We could use user contributed ebuilds attached to bugs as a way to
> bring Sunrise to the contributors attention just by posting a comment
> to the bug. If the contributor follows up, we get another user
> maintained ebuild in Sunrise, which is good, as the current developers
> don't have to do all the work. We already know some Sunrise
> contributors become developers so perhaps we can use this as a way to
> attract more contributors (both users and developers).
>
> Its probably a bad idea to send all the bugspam at the same time,
> Sunrise might be overwhelmed, which would be bad for Sunrise and user
> contributors who would feel let down
>
This is already done. darkside/idl0r did/do suggest sunrise to all maintainer-wanted bugs, that meet
some specific criteria. But have to say, while hundreds of messages where sent, there is not much
response from this until now.
--
Thomas Sachau
Gentoo Linux Developer
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 315 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 14:44 ` Richard Freeman
@ 2009-05-15 7:43 ` Thilo Bangert
2009-05-15 10:04 ` Marijn Schouten (hkBst)
2009-05-15 10:25 ` [gentoo-dev] " Richard Freeman
0 siblings, 2 replies; 36+ messages in thread
From: Thilo Bangert @ 2009-05-15 7:43 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 4174 bytes --]
Richard Freeman <rich0@gentoo.org> said:
> AllenJB wrote:
> > All that's going to happen is Gentoo will have many many buggy and
> > out of date packages in the MAIN TREE. Exactly where they shouldn't
> > be. You claim quality won't be sacrificed, but I simply can't see
> > this without any attempt to solve the manpower issues first.
> >
> > Isn't the purpose of this project already somewhat covered by
> > Sunrise?
>
> I have to agree with your points. We need to have quality standards
> for packages. Currently we have a couple of tiers:
>
> 1. Main tree - every ebuild has an official maintainer and gets prompt
> security updates/etc. New features might get a little more stale, but
> you aren't going to be running at risk if you only use the main tree
> and routinely emerge -u world. If a package falls behind on security
> it gets masked and booted.
>
> 2. Overlays - you're on your own and at the general mercy of the
> overlay maintainer.
>
> 3. Sunrise (just a special case of an overlay) - somewhere in-between.
> Again, you have to opt-in.
>
AFAIK, we have never explicitly made this distinction clear. if we had, we
would have to remove stuff from portage which doesnt live up to the
standards.
it is also not true from a more real world perspective: there are many
packages in portage that have a standard which is much lower than what is
in some overlays. and there are many packages in overlays which live up to
a quality standard way above portage's average.
if you want to exaggerate a bit, we have roughly 500 ebuilds in portage
which are maintainer-needed and have only a few users and thats why you
want to keep popular packages out of the tree?
its weird, how this whole thing started with wanting to accomodate our
users better and then other people come around and argue against it in
order to protect our users...
user who want protection run stable arch!
given the current state of the tree, its hypocritical to be against this
proposal, IMHO.
however, one could try to implement the above quality standards, possibly
by splitting up the tree.
this issue, as well as some others very similar to this one, have come up
many times before. I suggest we do something about it... (splitting the
tree or moving more stuff wholesale into portage and have a better rating
system... whatever)
Fedora is a much more current distribution than Gentoo - and has been for
a couple of years...
regards
Thilo
> I think that we still need to have defined levels of quality, so if we
> start putting unmaintained stuff in the main tree then we absolutely
> need to preserve a mechanism for users to indicate what level of
> quality they desire. Users running a typical install shouldn't
> inadvertently have dependencies pulled in which aren't fully controlled
> for security issues.
>
> Could something like sunrise be integrated into the main tree? Sure.
> However, there would need to be lots of rules and QA checks like
> non-sunrise packages not depending on sunrise packages and the sunrise
> packages are somehow clearly marked. Maybe even an ACCEPT_QUALITY =
> "good-luck-with-that" setting or something like that in make.conf. We
> might also need tiered levels of security in cvs. I'm not convinced
> that in the end it will be any better than just having those who are
> interested add an overlay to their tree.
>
> Maybe a better option would be a way to make overlays more seamless.
> Additionally we could have rating categories for overlays like
> "security responsiveness," "currency with upstream," etc. The gentoo
> project would ask overlays to declare their policies as a condition of
> being accessible via the seamless interface, and would drop overlays if
> they don't follow their policies. It would still be easy for users to
> pick non-standard overlays but it would be clear that they are
> venturing off on their own if they do this (just as is the case with
> layman today).
>
> Sure, I'd love to see an extra 1000 supported packages in portage, but
> the key is "supported", not just shoveled-in.
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-15 7:43 ` Thilo Bangert
@ 2009-05-15 10:04 ` Marijn Schouten (hkBst)
2009-05-15 10:44 ` Daniel Pielmeier
2009-05-15 10:25 ` [gentoo-dev] " Richard Freeman
1 sibling, 1 reply; 36+ messages in thread
From: Marijn Schouten (hkBst) @ 2009-05-15 10:04 UTC (permalink / raw
To: gentoo-dev
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Thilo Bangert wrote:
> Richard Freeman <rich0@gentoo.org> said:
>> AllenJB wrote:
>>> All that's going to happen is Gentoo will have many many buggy and
>>> out of date packages in the MAIN TREE. Exactly where they shouldn't
>>> be. You claim quality won't be sacrificed, but I simply can't see
>>> this without any attempt to solve the manpower issues first.
>>>
>>> Isn't the purpose of this project already somewhat covered by
>>> Sunrise?
>> I have to agree with your points. We need to have quality standards
>> for packages. Currently we have a couple of tiers:
>>
>> 1. Main tree - every ebuild has an official maintainer and gets prompt
>> security updates/etc. New features might get a little more stale, but
>> you aren't going to be running at risk if you only use the main tree
>> and routinely emerge -u world. If a package falls behind on security
>> it gets masked and booted.
>>
>> 2. Overlays - you're on your own and at the general mercy of the
>> overlay maintainer.
>>
>> 3. Sunrise (just a special case of an overlay) - somewhere in-between.
>> Again, you have to opt-in.
>>
>
> AFAIK, we have never explicitly made this distinction clear. if we had, we
> would have to remove stuff from portage which doesnt live up to the
> standards.
We should try to work with the maintainers of those packages to improve things.
> it is also not true from a more real world perspective: there are many
> packages in portage that have a standard which is much lower than what is
> in some overlays. and there are many packages in overlays which live up to
> a quality standard way above portage's average.
This is probably true, but without knowing which is which we can't do much about
it. Even if we did know, that still doesn't mean packages could be moved from
overlays to main tree, as they would instantly become unmaintained.
> if you want to exaggerate a bit, we have roughly 500 ebuilds in portage
> which are maintainer-needed and have only a few users and thats why you
> want to keep popular packages out of the tree?
If packages are popular enough someone will care enough to add and maintain them.
> its weird, how this whole thing started with wanting to accomodate our
> users better and then other people come around and argue against it in
> order to protect our users...
> user who want protection run stable arch!
Perhaps there are pros and cons to actually doing this, like with most things.
It seems like some are arguing that the value of having more ebuilds outweighs
the bad of having more less-maintained ebuilds. Others may feel differently.
> given the current state of the tree, its hypocritical to be against this
> proposal, IMHO.
See above.
> however, one could try to implement the above quality standards, possibly
> by splitting up the tree.
Overlays are effectively a splitting of the tree, so we are already there.
> this issue, as well as some others very similar to this one, have come up
> many times before. I suggest we do something about it... (splitting the
> tree or moving more stuff wholesale into portage and have a better rating
> system... whatever)
>
> Fedora is a much more current distribution than Gentoo - and has been for
> a couple of years...
Please elaborate what exactly you think Fedora does better than we do. I have no
first-hand experience with Fedora, but from what I read I had the impression
that sometimes they go with new stuff before it is ready, like KDE4 and pulseaudio.
I like about the current situation that we also have all those things available
AFAICS, but have very broad choices in how much we want to bleed.
IMO this is a different issue than having supposedly popular ebuilds not in main
tree.
I think there is a steady inflow of fresh developers from sunrise (and other
places). Does anyone have a chart? I'd also like to know from prospective
developers if they have trouble getting recruited, through sunrise or other
projects.
Marijn
- --
If you cannot read my mind, then listen to what I say.
Marijn Schouten (hkBst), Gentoo Lisp project, Gentoo ML
<http://www.gentoo.org/proj/en/lisp/>, #gentoo-{lisp,ml} on FreeNode
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkoNPjsACgkQp/VmCx0OL2x/lgCgrvL/3f0XqLJPEe6+BOCl/0R8
j3kAn1jLAW1flDAZt7wu9IuSMO3jtmZe
=szxf
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-15 7:43 ` Thilo Bangert
2009-05-15 10:04 ` Marijn Schouten (hkBst)
@ 2009-05-15 10:25 ` Richard Freeman
2009-05-19 23:51 ` Mart Raudsepp
1 sibling, 1 reply; 36+ messages in thread
From: Richard Freeman @ 2009-05-15 10:25 UTC (permalink / raw
To: gentoo-dev
Thilo Bangert wrote:
> AFAIK, we have never explicitly made this distinction clear. if we had, we
> would have to remove stuff from portage which doesnt live up to the
> standards.
>
I'm all for that. In reality we tend to leave them alone until a
security issue actually comes up, which is probably a reasonable
compromise (since it also takes work to remove them). In any case,
failure to completely meet a standard does not automatically imply that
the standard is worthless.
> it is also not true from a more real world perspective: there are many
> packages in portage that have a standard which is much lower than what is
> in some overlays. and there are many packages in overlays which live up to
> a quality standard way above portage's average.
>
I don't think anybody has issues with overlays that choose to have
higher quality standards than portage. I'm all for that. I'm concerned
with the quality level in portage - since that is what we attach our
name to. If some other repository wants to do a better job than more
power to them!
However, Gentoo cannot endorse "all overlays" as being official
repositories, because clearly there is no standard for quality when all
it takes to have an overlay is to set up an rsync or http server and put
some ebuilds on it.
> if you want to exaggerate a bit, we have roughly 500 ebuilds in portage
> which are maintainer-needed and have only a few users and thats why you
> want to keep popular packages out of the tree?
>
Actually, where any of those ebuilds cause problems I'm fine with
getting rid of them. I'm certainly not arguing for inconsistency. I'm
just suggesting that we shouldn't make the problem worse.
If a package is popular then somebody should volunteer to maintain it
(whether by becoming a gentoo dev or by starting their own overlay). If
that isn't happening than clearly the package isn't THAT important.
This is open source - if you have an itch, then scratch it! Don't just
complain that nobody else is scratching YOUR itch (even if it is a
popular itch).
In any case, my opinion is that for packages to be in portage they
should be of a certain level of quality, and a developer should be
accountable for the packages they commit. Anybody is welcome to grab
ebuilds out of CVS, screen them, and commit them. However, if they
cause havoc then the developer can't just say "but it was popular and
unmaintained, so I figured I'd just commit something without looking at
it." If a developer is willing to commit an appropriate amount of time
to QA then they essentially have become a maintainer and the package is
no-longer maintainer-wanted.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-15 10:04 ` Marijn Schouten (hkBst)
@ 2009-05-15 10:44 ` Daniel Pielmeier
2009-05-15 12:24 ` [gentoo-dev] " Duncan
0 siblings, 1 reply; 36+ messages in thread
From: Daniel Pielmeier @ 2009-05-15 10:44 UTC (permalink / raw
To: gentoo-dev
2009/5/15 Marijn Schouten (hkBst) <hkBst@gentoo.org>:
>
> Thilo Bangert wrote:
>>
>> Fedora is a much more current distribution than Gentoo - and has been for
>> a couple of years...
>
> Please elaborate what exactly you think Fedora does better than we do. I have no
> first-hand experience with Fedora, but from what I read I had the impression
> that sometimes they go with new stuff before it is ready, like KDE4 and pulseaudio.
> I like about the current situation that we also have all those things available
> AFAICS, but have very broad choices in how much we want to bleed.
> IMO this is a different issue than having supposedly popular ebuilds not in main
> tree.
>
AFAIK Fedora (formerly Red Hat Linux) is the playground for Red Hat
Enterprise Linux like Opensuse is for Suse Linux Enterprise. So it
makes more sense to compare it with the Gentoo unstable tree instead
of the stable one. Assuming this there is probably not a big
difference in the up-to-dateness.
--
Daniel Pielmeier
^ permalink raw reply [flat|nested] 36+ messages in thread
* [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
2009-05-15 10:44 ` Daniel Pielmeier
@ 2009-05-15 12:24 ` Duncan
2009-05-19 23:24 ` Mart Raudsepp
0 siblings, 1 reply; 36+ messages in thread
From: Duncan @ 2009-05-15 12:24 UTC (permalink / raw
To: gentoo-dev
Daniel Pielmeier <daniel.pielmeier@googlemail.com> posted
6142e6140905150344y4a8007b5wd352ffe891e49230@mail.gmail.com, excerpted
below, on Fri, 15 May 2009 12:44:47 +0200:
> 2009/5/15 Marijn Schouten (hkBst) <hkBst@gentoo.org>:
>>
>> Thilo Bangert wrote:
>>>
>>> Fedora is a much more current distribution than Gentoo - and has been
>>> for a couple of years...
>>
>> Please elaborate what exactly you think Fedora does better than we do.
>> I have no first-hand experience with Fedora, but from what I read I had
>> the impression that sometimes they go with new stuff before it is
>> ready, like KDE4 and pulseaudio. I like about the current situation
>> that we also have all those things available AFAICS, but have very
>> broad choices in how much we want to bleed. IMO this is a different
>> issue than having supposedly popular ebuilds not in main tree.
>>
> AFAIK Fedora is [Red Hat's unstable.] So it makes more sense to
> compare it with the Gentoo unstable tree instead of the stable
> one. Assuming this there is probably not a big difference in the
> up-to-dateness.
Well, yes and no. As the GP said, they sometimes go with new stuff
before it's ready -- before Gentoo even has it in-tree hard-masked let
alone ~arch, while it's still in the various project overlays. I know
they've had some serious issues with xorg on Intel GPUs at least, due to
running versions that aren't in our tree yet, only in the X overlay,
because Fedora is running clearly not even ~arch-ready packages,
sometimes even xorg prereleases.
Years ago we'd have put these in-tree but hard-masked for those who
wanted to try them. Now, depending on the package and Gentoo but more
likely as the complexity rises to meta-package levels, those who want to
try them must load an overlay. As someone who selectively unmasks and
tries these, having them in-tree but hard-masked is convenient, but I
understand why projects may prefer overlays in many cases.
However, none of this directly applies to the subject at hand, because
while we're talking new versions of packages already in-tree here, the
subject at hand is packages that aren't in-tree in any form yet.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 18:48 ` Thomas Sachau
@ 2009-05-17 9:00 ` Tobias Scherbaum
0 siblings, 0 replies; 36+ messages in thread
From: Tobias Scherbaum @ 2009-05-17 9:00 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 902 bytes --]
Am Donnerstag, den 14.05.2009, 20:48 +0200 schrieb Thomas Sachau:
> This is already done. darkside/idl0r did/do suggest sunrise to all maintainer-wanted bugs, that meet
> some specific criteria.
noticed that, and i'd like to give a "thanks guys" for doing so :)
> But have to say, while hundreds of messages where sent, there is not much
> response from this until now.
"not much" is not "no" response, maybe it would make it easier for users
to get active with sunrise if we'd have a shiny "x steps to commit to
sunrise" document maintained by our docs project (and also translated!).
Plus from what i've seen on the overlays' sunrise wiki one who'd like to
contribute needs to got to IRC to ask for an account - which most likely
lots of possible contributors are not familiar with. Make it as easy as
possible for those people! - oh and: promote it more actively.
wkr,
Tobias
[-- Attachment #2: Dies ist ein digital signierter Nachrichtenteil --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
2009-05-14 0:32 [gentoo-dev] RFC: Project proposal -- maintainer-wanted Mart Raudsepp
` (5 preceding siblings ...)
2009-05-14 18:24 ` Roy Bamford
@ 2009-05-17 18:08 ` Ryan Hill
2009-05-19 23:42 ` Mart Raudsepp
2009-05-28 7:55 ` [gentoo-dev] " Peter Volkov
7 siblings, 1 reply; 36+ messages in thread
From: Ryan Hill @ 2009-05-17 18:08 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1529 bytes --]
On Thu, 14 May 2009 03:32:12 +0300
Mart Raudsepp <leio@gentoo.org> wrote:
> 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.
Actually, I'm working on a "get the crap out of the tree" project that is
pretty much the exact opposite of this. ;)
But, things I like:
- metrics for package popularity (can we do gentoo-stats already?)
- encouraging teams and maintainers to take an interest in unmaintained
packages
- keeping track of maintainer-wanted/needed packages through categorization,
etc.
- proxy-maintainers
These things I think would benefit both projects, as well as several others.
I would actually rather see our overall package count dropping than growing,
but if we're adding quality, maintained stuff and tossing out the garbage then
I guess that's an improvement too.
--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
2009-05-15 12:24 ` [gentoo-dev] " Duncan
@ 2009-05-19 23:24 ` Mart Raudsepp
0 siblings, 0 replies; 36+ messages in thread
From: Mart Raudsepp @ 2009-05-19 23:24 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 4142 bytes --]
On Fri, 2009-05-15 at 12:24 +0000, Duncan wrote:
> Daniel Pielmeier <daniel.pielmeier@googlemail.com> posted
> 6142e6140905150344y4a8007b5wd352ffe891e49230@mail.gmail.com, excerpted
> below, on Fri, 15 May 2009 12:44:47 +0200:
>
> > 2009/5/15 Marijn Schouten (hkBst) <hkBst@gentoo.org>:
> >>
> >> Thilo Bangert wrote:
> >>>
> >>> Fedora is a much more current distribution than Gentoo - and has been
> >>> for a couple of years...
> >>
> >> Please elaborate what exactly you think Fedora does better than we do.
> >> I have no first-hand experience with Fedora, but from what I read I had
> >> the impression that sometimes they go with new stuff before it is
> >> ready, like KDE4 and pulseaudio. I like about the current situation
> >> that we also have all those things available AFAICS, but have very
> >> broad choices in how much we want to bleed. IMO this is a different
> >> issue than having supposedly popular ebuilds not in main tree.
> >>
> > AFAIK Fedora is [Red Hat's unstable.] So it makes more sense to
> > compare it with the Gentoo unstable tree instead of the stable
> > one. Assuming this there is probably not a big difference in the
> > up-to-dateness.
>
> Well, yes and no. As the GP said, they sometimes go with new stuff
> before it's ready -- before Gentoo even has it in-tree hard-masked let
> alone ~arch, while it's still in the various project overlays. I know
> they've had some serious issues with xorg on Intel GPUs at least, due to
> running versions that aren't in our tree yet, only in the X overlay,
> because Fedora is running clearly not even ~arch-ready packages,
> sometimes even xorg prereleases.
I believe you are thinking of rawhide.
Fedora and quite most other distributions work fundamentally different.
We have a gradually moving tree, as we can do that by being source
based.
Fedora and other distributions are doing releases, which involves
switching to a newer repository branch with dist-upgrade and so on.
They release a new version typically every 6 month, we release new major
versions of packages all the time (considering the whole set).
I'd say that at the point of binary distribution releases their released
trees are somewhere between our ~arch and stable tree, while within a
month or two, they become similar to our stable tree until our continous
releases overcome it with newer versions.
Fedora has xorg prereleases in what they call "rawhide". This is what
will become a new release in the future, as they have ~6 month cycles.
It's unstable on purpose, as they are thriving towards being stable with
that repository at the time of the planned next release, while having up
to date packages around the time of the release (with a ~1 month
stabilization period before the release time). That's the fundamental
difference, and where we can have an advantage over them in addition to
other things coming from being source based.
> Years ago we'd have put these in-tree but hard-masked for those who
> wanted to try them. Now, depending on the package and Gentoo but more
> likely as the complexity rises to meta-package levels, those who want to
> try them must load an overlay. As someone who selectively unmasks and
> tries these, having them in-tree but hard-masked is convenient, but I
> understand why projects may prefer overlays in many cases.
We do tend to prefer overlays in many cases for unstable releases.
The project proposal at hand is of course talking about packages that
are not available at all in the main tree yet. Overlays are quite nice
for tracking unstable releases of package sets that do have their
upstream stable releases in official tree.
> However, none of this directly applies to the subject at hand, because
> while we're talking new versions of packages already in-tree here, the
> subject at hand is packages that aren't in-tree in any form yet.
Sorry, still felt like replying with my view on Gentoo vs dist-upgraded
distros :)
--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 18:24 ` Roy Bamford
2009-05-14 18:48 ` Thomas Sachau
@ 2009-05-19 23:35 ` Mart Raudsepp
1 sibling, 0 replies; 36+ messages in thread
From: Mart Raudsepp @ 2009-05-19 23:35 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 3186 bytes --]
On Thu, 2009-05-14 at 19:24 +0100, Roy Bamford wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 2009.05.14 01:32, Mart Raudsepp wrote:
> > Hello,
> >
> [snip]
>
> > 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.
> >
> [snip]
> >
> > Discuss! :)
> >
> > Mart Raudsepp
> > Gentoo Developer
> > Mail: leio@gentoo.org
> > Weblog: http://planet.gentoo.org/developers/leio
> >
>
> Mart,
>
> I'm against for many of the reasons AllanJB outlined. There is no point
> in adding more unmaintained packages to the tree. Over time, the
> average quality of the tree will suffer.
I have not proposed adding unmaintained packages to the tree. I have
proposed adding packages to the tree that are maintained. The
maintainer-wanted team maintains them actively until a specific team is
interested in taking over.
Based on other replies to the thread, it seems no-one believes that a
special team could add only so many packages that they are capable of
maintaining in good quality.
Also it has been brought up many times that if there is a popular
package not yet in the tree, there will be someone to add and maintain
it. But that doesn't seem to be the case when looking at existing
maintainer-wanted bugs. Also by having a team for this, the whole team
is accountable. If a maintainer-wanted ebuild is added by this team, it
is done as a team - if the person in the team most interested in it is
busy otherwise, the team will still take care of its bugs and quality
and bumps.
> We could use user contributed ebuilds attached to bugs as a way to
> bring Sunrise to the contributors attention just by posting a comment
> to the bug. If the contributor follows up, we get another user
> maintained ebuild in Sunrise, which is good, as the current developers
> don't have to do all the work. We already know some Sunrise
> contributors become developers so perhaps we can use this as a way to
> attract more contributors (both users and developers).
Meanwhile there is no-one to add packages that are wanted by many users
to the official tree. This project is meant as a remedy for that. The
proposal also lists various ways for actually finding out what packages
are the ones most beneficial to have in the official tree - as opposed
to unknown quality attachment in bugzilla, sunrise overlay, other
overlays or requests in bug entries without an attached ebuild - as to
be able to inflict as much good for the distribution as possible, given
the teams current capacity.
--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
2009-05-17 18:08 ` [gentoo-dev] " Ryan Hill
@ 2009-05-19 23:42 ` Mart Raudsepp
0 siblings, 0 replies; 36+ messages in thread
From: Mart Raudsepp @ 2009-05-19 23:42 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2700 bytes --]
On Sun, 2009-05-17 at 12:08 -0600, Ryan Hill wrote:
> On Thu, 14 May 2009 03:32:12 +0300
> Mart Raudsepp <leio@gentoo.org> wrote:
>
> > 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.
>
> Actually, I'm working on a "get the crap out of the tree" project that is
> pretty much the exact opposite of this. ;)
I don't think it opposes it much, maybe only 2-5% of maintainer-needed
packages.
Popular packages aren't crap. Their packaging ease might be, but
obviously people want to use those if they are popular, hence we can't
dub them really "crap".
We could say those packages are "crap" that get building bugs filed by
tinderbox runs from Patrick, Diego and other such people, while no-one
else has cared. The maintainer-wanted project would not be interested in
any such packages. Those are obviously dead applications/libraries that
are in no way popular and very beneficial to carry in the official tree.
> But, things I like:
>
> - metrics for package popularity (can we do gentoo-stats already?)
Yeah, that'd be cool. Some other metrics ideas I brought out that can be
used for this projects purposes while there is no gentoo-stats.
> - encouraging teams and maintainers to take an interest in unmaintained
> packages
It being a project/team making it more likely it doesn't degrade over
time when there is no dedicated team maintaining this. Maybe we could
make it so that when a package maintained by someone specific
(individual or team) that was taken over from maintainer-wanted would
drop back to maintainer-wanted team instead of maintainer-needed herd,
as the latter currently has technically no members.
> - keeping track of maintainer-wanted/needed packages through categorization,
> etc.
> - proxy-maintainers
>
> These things I think would benefit both projects, as well as several others.
>
> I would actually rather see our overall package count dropping than growing,
> but if we're adding quality, maintained stuff and tossing out the garbage then
> I guess that's an improvement too.
Indeed.
--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-15 10:25 ` [gentoo-dev] " Richard Freeman
@ 2009-05-19 23:51 ` Mart Raudsepp
2009-05-20 0:55 ` [gentoo-dev] " Duncan
0 siblings, 1 reply; 36+ messages in thread
From: Mart Raudsepp @ 2009-05-19 23:51 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2886 bytes --]
On Fri, 2009-05-15 at 06:25 -0400, Richard Freeman wrote:
> > if you want to exaggerate a bit, we have roughly 500 ebuilds in
> portage
> > which are maintainer-needed and have only a few users and thats why
> you
> > want to keep popular packages out of the tree?
> >
>
> Actually, where any of those ebuilds cause problems I'm fine with
> getting rid of them. I'm certainly not arguing for inconsistency.
> I'm
> just suggesting that we shouldn't make the problem worse.
I'm not suggesting to make the problem worse either. On the contrary.
maintainer-needed packages that clearly are used to close by no-one or
no-one (based on no-one reporting build bugs or version bump requests or
whatever) should probably indeed be last-rited and removed from the
tree, especially if there is no active upstream.
This seems to be what the treecleaners project is about, and
maintainer-wanted is not meant to have anything to do with that. It is
about getting popular packages (based on various metrics) into the
official tree for easy access and with known quality.
>
> If a package is popular then somebody should volunteer to maintain it
> (whether by becoming a gentoo dev or by starting their own overlay).
> If
> that isn't happening than clearly the package isn't THAT important.
> This is open source - if you have an itch, then scratch it! Don't
> just
> complain that nobody else is scratching YOUR itch (even if it is a
> popular itch).
I don't think we have all topics covered by active teams. When
maintainer-wanted team packages something in-tree that would be suitable
for a certain existing team, the categorization in the proposed listing
of maintainer-wanted packages would imply that, so that once they are
able to handle more they can take over if it is well suited for their
set of packages.
Until such a time this kind of packages would be available in great,
good or acceptable quality to the users.
>
> In any case, my opinion is that for packages to be in portage they
> should be of a certain level of quality, and a developer should be
> accountable for the packages they commit. Anybody is welcome to grab
> ebuilds out of CVS, screen them, and commit them. However, if they
> cause havoc then the developer can't just say "but it was popular and
> unmaintained, so I figured I'd just commit something without looking
> at
> it." If a developer is willing to commit an appropriate amount of
> time
> to QA then they essentially have become a maintainer and the package
> is
> no-longer maintainer-wanted.
The maintainer-wanted team would effectively aggregate those people
together, so that the end result would be better quality, quicker
response times and so on.
--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 14:50 ` Richard Freeman
@ 2009-05-19 23:54 ` Mart Raudsepp
2009-05-20 15:36 ` Richard Freeman
0 siblings, 1 reply; 36+ messages in thread
From: Mart Raudsepp @ 2009-05-19 23:54 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1898 bytes --]
On Thu, 2009-05-14 at 10:50 -0400, Richard Freeman wrote:
> Mart Raudsepp wrote:
> >
> > Liking and using the package yourself shouldn't be a prerequisite for a
> > package getting to be in-tree by the maintainer-wanted team.
>
> How about actually maintaining the package?
Yes, actually maintaining the package would be a standard for the
project.
> For example, user contributes ebuild for foo-1.0. I don't use it or
> like it, but I go ahead and throw it into portage. User logs bug that
> foo-1.0 wipes out random files from time to time. Nobody looks at said
> bug since nobody owns foo, and bug starts getting 3000 "me-too!"
> comments.
The maintainer-wanted team owns that foo package then, which is why
having a different mail alias than the existing one for "new package
requests that aren't in gentoo tree yet" would be a good idea.
> Some charitable developer takes a look and the problem isn't
> obvious and offers to just mask the package. Now 3000 people running
> foo are upset for it being de-supported (when it wasn't supported in the
> first place).
>
> Wouldn't it make more sense for people who like the foo-1.0 ebuild to
> just stick it in their own ebuild or an overlay and be on their own
> (since they're really on their own either way)? Or to move it to
> sunrise or some other place where it might actually get some level of
> support?
I am proposing to have it in the official tree and not having such a
situation happen at all by random dev adding it to tree without the
intention to maintain it.
> If Gentoo is going to distribute an ebuild Gentoo should
> Do-It-Right(TM). Why put our name on something we don't really want to
> care for?
The intention would be to Do-It-Right(TM).
--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
2009-05-19 23:51 ` Mart Raudsepp
@ 2009-05-20 0:55 ` Duncan
2009-06-01 23:17 ` Mart Raudsepp
0 siblings, 1 reply; 36+ messages in thread
From: Duncan @ 2009-05-20 0:55 UTC (permalink / raw
To: gentoo-dev
Mart Raudsepp <leio@gentoo.org> posted
1242777068.30374.30.camel@localhost, excerpted below, on Wed, 20 May 2009
02:51:08 +0300:
> It is about getting popular packages (based on various metrics) into the
> official tree for easy access and with known quality.
Perhaps some concrete examples of packages you have in mind might be
useful. I list in the footnote[1] a couple I originally merged from
sunrise, that are now in-tree. I that the type of package you had in
mind? What /about/ sunrise packages? Will you be working with them to
bring "popular" packages from there in-tree too?
Of course in your case the ebuilds aren't in the tree yet, but bug
numbers for apps you believe fit the "popular" description might be
useful. "Popular packages" is a nebulous enough term on its own, that
some examples might help.
Also, an example or two of what you might consider a borderline case,
that you might consider adding if the load on the proposed project wasn't
too high already, but would reject if it was. Feel free to add comments
or explanations on how you came to that conclusion, both for the popular
and borderline examples, as well, if you think it necessary.
.....
[1] I still use sys-apps/moreutils.
The other one was www-plugins/swfdec-mozilla and its dep media-libs-
swfdec, which I had some trouble with and eventually unmerged in favor of
a couple of youtube downloaders, since youtube was what I mainly used
swfdec for anyway.
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-19 23:54 ` Mart Raudsepp
@ 2009-05-20 15:36 ` Richard Freeman
2009-06-01 21:19 ` Mart Raudsepp
0 siblings, 1 reply; 36+ messages in thread
From: Richard Freeman @ 2009-05-20 15:36 UTC (permalink / raw
To: gentoo-dev
Mart Raudsepp wrote:
>
> The maintainer-wanted team owns that foo package then, which is why
> having a different mail alias than the existing one for "new package
> requests that aren't in gentoo tree yet" would be a good idea.
>
Ok, I think I see where you're coming from. Essentially
maintainer-wanted is a group for people who want to collectively manage
ebuilds that don't otherwise fall into any particular project/herd.
Almost like a "misc" herd.
If the packages are actually being maintained then I have no issues at
all with the proposal - in fact I'd endorse it (for what little that is
worth). However "maintainer-wanted" seems like a bit of a misnomer -
these ebuilds would in fact have a maintainer. Perhaps another name
could be used so that it is easy to distinguish between:
1. Packages not in the tree (bugzilla requests/etc).
2. Packages in the tree that truly nobody is caring for.
3. Packages in the tree that the proposed project is caring for but
would love to see adopted into another herd/project.
4. Packages that are part of a more dedicated project/herd, or which
have attention from one or more particular developers.
I don't question the value in having group #3 which I think is what
you're proposing. But, perhaps it should have a specific name/alias so
that we can tell that a package belongs to it. Your proposed team could
scour #1/2 for new builds, and bump builds in #3 back to #2 if
necessary. Treecleaners would prune #2 and ignore #3. Of course,
cooperation with Sunrise would also be a plus.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-14 0:32 [gentoo-dev] RFC: Project proposal -- maintainer-wanted Mart Raudsepp
` (6 preceding siblings ...)
2009-05-17 18:08 ` [gentoo-dev] " Ryan Hill
@ 2009-05-28 7:55 ` Peter Volkov
2009-06-01 21:24 ` Mart Raudsepp
7 siblings, 1 reply; 36+ messages in thread
From: Peter Volkov @ 2009-05-28 7:55 UTC (permalink / raw
To: gentoo-dev
В Чтв, 14/05/2009 в 03:32 +0300, Mart Raudsepp пишет:
> Project maintainer-wanted
> =========================
Mart, I think that it's good idea to create such project but with a
different goals. I think currently maintainer-wanted alias is missed by
most developers: new packages are assigned there and from time to time
random developer picks package he needs or user moves ebuild into
Sunrise but nobody actually cares about packages/mail going there in
general. The goal of maintainer-wanted project could be just gather
statistics and highlighting most popular/interesting packages there.
Something like "Top 10 most popular maintainer-wanted packages" monthly
e-mail could be really useful.
Cheers,
--
Peter.
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-20 15:36 ` Richard Freeman
@ 2009-06-01 21:19 ` Mart Raudsepp
0 siblings, 0 replies; 36+ messages in thread
From: Mart Raudsepp @ 2009-06-01 21:19 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2751 bytes --]
On K, 2009-05-20 at 11:36 -0400, Richard Freeman wrote:
> Mart Raudsepp wrote:
> >
> > The maintainer-wanted team owns that foo package then, which is why
> > having a different mail alias than the existing one for "new package
> > requests that aren't in gentoo tree yet" would be a good idea.
> >
>
> Ok, I think I see where you're coming from. Essentially
> maintainer-wanted is a group for people who want to collectively manage
> ebuilds that don't otherwise fall into any particular project/herd.
> Almost like a "misc" herd.
>
> If the packages are actually being maintained then I have no issues at
> all with the proposal - in fact I'd endorse it (for what little that is
> worth). However "maintainer-wanted" seems like a bit of a misnomer -
> these ebuilds would in fact have a maintainer. Perhaps another name
> could be used so that it is easy to distinguish between:
>
> 1. Packages not in the tree (bugzilla requests/etc).
> 2. Packages in the tree that truly nobody is caring for.
> 3. Packages in the tree that the proposed project is caring for but
> would love to see adopted into another herd/project.
> 4. Packages that are part of a more dedicated project/herd, or which
> have attention from one or more particular developers.
>
> I don't question the value in having group #3 which I think is what
> you're proposing. But, perhaps it should have a specific name/alias so
> that we can tell that a package belongs to it. Your proposed team could
> scour #1/2 for new builds, and bump builds in #3 back to #2 if
> necessary. Treecleaners would prune #2 and ignore #3. Of course,
> cooperation with Sunrise would also be a plus.
Yes, that's all pretty much what I have in mind here. I have also
acknowledge in various e-mails that we need a better naming for the
"herd" name (not necessarily for the team) to distinguish bugzilla bugs
that are maintained by this proposed team and new package request bugs
that are still waiting for someone to pick them up.
Also I hope the flow from #3 to #2 doesn't end up happening often and
that the team would be caring about the packages in acceptable quality
until it can flow to under #4. So some (in)formal policies amongst the
team members to ensure the team doesn't get overwhelmed would seem
appropriate.
I hope the person I found to lead this project (if in the lack of others
willing to do that when it becomes an actual project) clarifies things
in the project proposal draft that opened this thread, which could then
in the end be mostly re-used as the project page text on gentoo.org
--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted
2009-05-28 7:55 ` [gentoo-dev] " Peter Volkov
@ 2009-06-01 21:24 ` Mart Raudsepp
0 siblings, 0 replies; 36+ messages in thread
From: Mart Raudsepp @ 2009-06-01 21:24 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 1905 bytes --]
On N, 2009-05-28 at 11:55 +0400, Peter Volkov wrote:
> В Чтв, 14/05/2009 в 03:32 +0300, Mart Raudsepp пишет:
> > Project maintainer-wanted
> > =========================
>
> Mart, I think that it's good idea to create such project but with a
> different goals. I think currently maintainer-wanted alias is missed by
> most developers: new packages are assigned there and from time to time
> random developer picks package he needs or user moves ebuild into
> Sunrise but nobody actually cares about packages/mail going there in
> general. The goal of maintainer-wanted project could be just gather
> statistics and highlighting most popular/interesting packages there.
> Something like "Top 10 most popular maintainer-wanted packages" monthly
> e-mail could be really useful.
Good idea in my opinion, but in a different way - the team could
maintain such a (unordered) list with varying package count size and
pick the packages to put to portage tree by them out of that list as
well when the manpower allows to maintain the package in question. But
having a list before actually packaging them in official tree could
serve as another list where other maintainers could pick them up and
package them before maintainer-wanted would, skipping the otherwise
supposedly short time maintainer-wanted would be maintaining it --
packages that are maintained by maintainer-wanted would have a list to
pick from as well, and the interested maintainer could find it from that
one too.
Above when I said "maintainer-wanted" I meant the herd/team with another
more suitable name then to not confuse with bugs assigned to that alias
that are still not maintained by anyone in the official tree (yes,
co-operation with Sunrise and the like I'd see as important).
--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
* Re: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted
2009-05-20 0:55 ` [gentoo-dev] " Duncan
@ 2009-06-01 23:17 ` Mart Raudsepp
0 siblings, 0 replies; 36+ messages in thread
From: Mart Raudsepp @ 2009-06-01 23:17 UTC (permalink / raw
To: gentoo-dev
[-- Attachment #1: Type: text/plain, Size: 2873 bytes --]
On K, 2009-05-20 at 00:55 +0000, Duncan wrote:
> Mart Raudsepp <leio@gentoo.org> posted
> 1242777068.30374.30.camel@localhost, excerpted below, on Wed, 20 May 2009
> 02:51:08 +0300:
>
> > It is about getting popular packages (based on various metrics) into the
> > official tree for easy access and with known quality.
>
> Perhaps some concrete examples of packages you have in mind might be
> useful.
A big part of the thing is to get things better qualified in popularity.
Encouraging users on maintainer-wanted bugs (automatically adding a link
to a describing page if assignee=maintainer-wanted?) to leave their
votes appropriately, automated methods to sort bugs based on comment and
activity, comparing with popularity metrics in other distributions that
have something like the not-really-existing yet gentoo-stats, perhaps
working on gentoo-stats, etc etc.
> I list in the footnote[1] a couple I originally merged from
> sunrise, that are now in-tree. I that the type of package you had in
> mind? What /about/ sunrise packages? Will you be working with them to
> bring "popular" packages from there in-tree too?
>
> Of course in your case the ebuilds aren't in the tree yet, but bug
> numbers for apps you believe fit the "popular" description might be
> useful. "Popular packages" is a nebulous enough term on its own, that
> some examples might help.
These metrics should be worked out by an upcoming team then, not
ignoring common sense. But perhaps a few examples then:
miro
songbird
moovida (previously known as Elisa Media Center)
paperbox
shutter
I see many of the ones I was able to list seem to be either complex
deptree packages that no-one has been motivated enough yet to push
through (so hopefully once that hard work gets done once, a dedicated
maintainer is found easily), and stuff that would be cool to use once
it's easily available and found, but not something people very much
depend on to care that much alone for themselves, hence a team finding
such packages at first could be useful.
> Also, an example or two of what you might consider a borderline case,
> that you might consider adding if the load on the proposed project wasn't
> too high already, but would reject if it was. Feel free to add comments
> or explanations on how you came to that conclusion, both for the popular
> and borderline examples, as well, if you think it necessary.
>
> .....
>
> [1] I still use sys-apps/moreutils.
>
> The other one was www-plugins/swfdec-mozilla and its dep media-libs-
> swfdec, which I had some trouble with and eventually unmerged in favor of
> a couple of youtube downloaders, since youtube was what I mainly used
> swfdec for anyway.
--
Mart Raudsepp
Gentoo Developer
Mail: leio@gentoo.org
Weblog: http://planet.gentoo.org/developers/leio
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 36+ messages in thread
end of thread, other threads:[~2009-06-01 23:16 UTC | newest]
Thread overview: 36+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-05-14 0:32 [gentoo-dev] RFC: Project proposal -- maintainer-wanted Mart Raudsepp
2009-05-14 1:24 ` Gokdeniz Karadag
2009-05-14 1:27 ` AllenJB
2009-05-14 14:44 ` Richard Freeman
2009-05-15 7:43 ` Thilo Bangert
2009-05-15 10:04 ` Marijn Schouten (hkBst)
2009-05-15 10:44 ` Daniel Pielmeier
2009-05-15 12:24 ` [gentoo-dev] " Duncan
2009-05-19 23:24 ` Mart Raudsepp
2009-05-15 10:25 ` [gentoo-dev] " Richard Freeman
2009-05-19 23:51 ` Mart Raudsepp
2009-05-20 0:55 ` [gentoo-dev] " Duncan
2009-06-01 23:17 ` Mart Raudsepp
2009-05-14 1:47 ` [gentoo-dev] " Jeremy Olexa
2009-05-14 5:41 ` [gentoo-dev] " Duncan
2009-05-14 5:54 ` Patrick Lauer
2009-05-14 12:49 ` Alexander Færøy
2009-05-14 14:13 ` Nirbheek Chauhan
2009-05-14 9:09 ` Christian Faulhammer
2009-05-14 10:12 ` [gentoo-dev] " Mart Raudsepp
2009-05-14 17:06 ` Thomas Sachau
2009-05-14 6:53 ` Pacho Ramos
2009-05-14 11:02 ` Markos Chandras
2009-05-14 14:23 ` Mart Raudsepp
2009-05-14 14:50 ` Richard Freeman
2009-05-19 23:54 ` Mart Raudsepp
2009-05-20 15:36 ` Richard Freeman
2009-06-01 21:19 ` Mart Raudsepp
2009-05-14 18:24 ` Roy Bamford
2009-05-14 18:48 ` Thomas Sachau
2009-05-17 9:00 ` Tobias Scherbaum
2009-05-19 23:35 ` Mart Raudsepp
2009-05-17 18:08 ` [gentoo-dev] " Ryan Hill
2009-05-19 23:42 ` Mart Raudsepp
2009-05-28 7:55 ` [gentoo-dev] " Peter Volkov
2009-06-01 21:24 ` Mart Raudsepp
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox