From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1M4XvW-0007Ry-3z for garchives@archives.gentoo.org; Thu, 14 May 2009 10:12:34 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id A7E17E039D; Thu, 14 May 2009 10:12:32 +0000 (UTC) Received: from smtp-out.neti.ee (smtp-out.neti.ee [194.126.126.44]) by pigeon.gentoo.org (Postfix) with ESMTP id 59FFDE039D for ; Thu, 14 May 2009 10:12:32 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by MXR-4.estpak.ee (Postfix) with ESMTP id 79E9725AC5B for ; Thu, 14 May 2009 13:12:32 +0300 (EEST) X-Virus-Scanned: amavisd-new at Relay4.estpak.ee Received: from smtp-out.neti.ee ([127.0.0.1]) by localhost (MXR-4.estpak.ee [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VD1HIXyeq6Fn for ; Thu, 14 May 2009 13:12:31 +0300 (EEST) Received: from Relayhost1.neti.ee (Relayhost1 [88.196.174.141]) by MXR-4.estpak.ee (Postfix) with ESMTP id D9D6444D5B for ; Thu, 14 May 2009 13:12:31 +0300 (EEST) X-SMTP-Auth-NETI-Businesmail: no Subject: Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted From: Mart Raudsepp To: gentoo-dev@lists.gentoo.org In-Reply-To: <4A0B783C.2000501@gentoo.org> References: <1242261133.23088.82.camel@localhost> <4A0B783C.2000501@gentoo.org> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="=-PDDLKPumkhYww9GUUiRv" Date: Thu, 14 May 2009 13:12:27 +0300 Message-Id: <1242295947.17967.33.camel@localhost> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 X-Mailer: Evolution 2.22.0 X-Archives-Salt: f443d9c1-f2e8-4db3-995a-a6dc0a079213 X-Archives-Hash: 80393fba3682cd5f0bfc5c9e5c3af822 --=-PDDLKPumkhYww9GUUiRv Content-Type: text/plain Content-Transfer-Encoding: quoted-printable 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. > >=20 > Hmm, I wonder what the point is when there is 400 maintainer-needed bugs=20 > 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=20 > uses more developer time from a pool of "not enough time" that exists=20 > 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=20 > know about sunrise, or c) don't know enough about ebuilds to contribute=20 > 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=20 > work. Keep in mind, I am against pretty much any overlay, I think work=20 > should be kept in the main tree. But, for ebuild maintenance with=20 > 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=20 > 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=20 > tree, very similar to the sunrise project. Very similar to this proposal=20 > 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 >=20 > [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/ --=20 Mart Raudsepp Gentoo Developer Mail: leio@gentoo.org Weblog: http://planet.gentoo.org/developers/leio --=-PDDLKPumkhYww9GUUiRv Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.8 (GNU/Linux) iEYEABECAAYFAkoL7osACgkQkeYb6olFHJc/ggCg8wSNSpijroMVijnZJeZRitUm CfcAoP2UKXUKm8GtZG5LIYIYea6BON7Y =iKhs -----END PGP SIGNATURE----- --=-PDDLKPumkhYww9GUUiRv--