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 1M4Tho-0007T0-FS for garchives@archives.gentoo.org; Thu, 14 May 2009 05:42:08 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 08F61E043B; Thu, 14 May 2009 05:42:07 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id B7B86E043B for ; Thu, 14 May 2009 05:42:06 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 5E57965B0F for ; Thu, 14 May 2009 05:42:06 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -2.885 X-Spam-Level: X-Spam-Status: No, score=-2.885 required=5.5 tests=[AWL=0.714, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zW++a65FJjf8 for ; Thu, 14 May 2009 05:42:00 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTP id 5D62965607 for ; Thu, 14 May 2009 05:41:58 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1M4ThY-0007s8-FA for gentoo-dev@gentoo.org; Thu, 14 May 2009 05:41:52 +0000 Received: from ip68-231-21-207.ph.ph.cox.net ([68.231.21.207]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 May 2009 05:41:52 +0000 Received: from 1i5t5.duncan by ip68-231-21-207.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 14 May 2009 05:41:52 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: RFC: Project proposal -- maintainer-wanted Date: Thu, 14 May 2009 05:41:39 +0000 (UTC) Message-ID: References: <1242261133.23088.82.camel@localhost> <4A0B783C.2000501@gentoo.org> 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 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-21-207.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: f5dc4f34-3196-4885-94ac-386a9b700a20 X-Archives-Hash: a02f640cfa4a3c8aa0e5c268632ee2c0 Jeremy Olexa 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? = =20 If it's not duplicative, map out the difference and the proposed=20 relationship of apparently duplicative projects. Maybe you just want Sunrise in the main tree instead of as a dedicated,=20 supervised overlay. There were people with VERY strong feelings against=20 Sunrise, to the point I believe at least one dev opposing it resigned=20 over it and other boosting it were disciplined. Are you ready to take on= =20 that sort of opposition to get it in-tree? Maybe it's time to have that=20 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=20 existing m-needed packages begging for care in the tree, just to =20 effectively shove a bunch more in. > 2) proxy maint project[2] - Where a group helps users commit to the mai= n > tree, very similar to the sunrise project. Very similar to this proposa= l > but better conserves our developer time. Yet another existing solution this proposal would seem to duplicate. If=20 it's different, map out how and how the relationship in the apparent=20 overlap should be managed. If there's a place for the new project and maybe there is, the=20 differences from and relationship with the Sunrise and proxy-maint=20 projects, and the method of bringing in or justification for ignoring the= =20 hundreds of existing m-needed packages while arguably creating more,=20 needs mapped out. Alternatively, bend the proposal into a status change=20 for one or all of the above, and call a debate on that. --=20 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