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 1M4eOD-00019s-ME for garchives@archives.gentoo.org; Thu, 14 May 2009 17:06:37 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C427FE014E; Thu, 14 May 2009 17:06:13 +0000 (UTC) Received: from tommyserver.de (tommyserver.de [85.14.217.158]) by pigeon.gentoo.org (Postfix) with ESMTP id 8484DE014E for ; Thu, 14 May 2009 17:06:13 +0000 (UTC) Received: from [192.168.178.22] (Q5ccb.q.pppool.de [89.53.92.203]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by tommyserver.de (Postfix) with ESMTPSA id 183A914BBD10 for ; Thu, 14 May 2009 19:06:10 +0200 (CEST) Message-ID: <4A0C4F7A.2020006@gentoo.org> Date: Thu, 14 May 2009 19:06:02 +0200 From: Thomas Sachau 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 To: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] RFC: Project proposal -- maintainer-wanted References: <1242261133.23088.82.camel@localhost> <4A0B783C.2000501@gentoo.org> <1242295947.17967.33.camel@localhost> In-Reply-To: <1242295947.17967.33.camel@localhost> X-Enigmail-Version: 0.95.7 OpenPGP: id=211CA2D4 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigA23EE4E1A6ABC83312EDD2FB" X-Archives-Salt: 851bfc1a-94d5-46ec-85dc-4eddc440053b X-Archives-Hash: 093711fc9ee3155eeb921315fec31d9d This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigA23EE4E1A6ABC83312EDD2FB Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mart Raudsepp schrieb: >> 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 contribut= e=20 >> to sunrise, then we need to fix[1] that. >=20 > 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, the= y > 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 i= n > the official tree. I think, you overrate the possible additional free time that developers a= re 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 th= e main tree and maintain it there. If a dev would like to add a popular package, also not being personally i= nterested, he can still do it, nothing prevents him from that. But this does not happen and i think, there is a simple reason: The numbe= r 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 bec= ause 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 discuss= ed, 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 wh= atever), 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 o= r 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, contri= buting, learning and proxy maintaining their ebuilds, would be able to get their work to some audien= ce (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 b= ranch not accessable via layman nor does it automaticly write to the main tree. These contribution= s then get currently moved to the reviewed tree (which is what users get via layman) after some sunr= ise 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 recr= uited as ebuild deveopers. With this proposal, we could recruite new people to work on things they a= re 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. --=20 Thomas Sachau Gentoo Linux Developer --------------enigA23EE4E1A6ABC83312EDD2FB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iJwEAQEKAAYFAkoMT4AACgkQG7kqcTWJkGfjOwP+KdrXDYxm0bDP0g23IHLRofoJ XaChiPi14ebgnmzVmFpPIDh+omMBt4jMYHorqiIQnrfF02j29vhHdTLI5x4bAZDs b6FRKi10qlDNlmnXZ+Gh8hQ+oou7HpGUZUmSu4wMgUpQHe2QMDhGzQHte+qfsjdz iRzCOmpEeY/XJwUJXBc= =CiaZ -----END PGP SIGNATURE----- --------------enigA23EE4E1A6ABC83312EDD2FB--