From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.62) (envelope-from ) id 1HwQff-0007YC-BG for garchives@archives.gentoo.org; Thu, 07 Jun 2007 22:41:35 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l57MeblY010951; Thu, 7 Jun 2007 22:40:37 GMT Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by robin.gentoo.org (8.14.0/8.14.0) with ESMTP id l57McdrU008617 for ; Thu, 7 Jun 2007 22:38:40 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id B9E7264EFB for ; Thu, 7 Jun 2007 22:38:39 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: -0.75 X-Spam-Level: X-Spam-Status: No, score=-0.75 required=5.5 tests=[AWL=-0.750] 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 JUrJeKiihyQi for ; Thu, 7 Jun 2007 22:38:38 +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 C3E9D64425 for ; Thu, 7 Jun 2007 22:38:37 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1HwQcY-0007W0-QM for gentoo-dev@gentoo.org; Fri, 08 Jun 2007 00:38:22 +0200 Received: from ip68-231-15-181.ph.ph.cox.net ([68.231.15.181]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Jun 2007 00:38:22 +0200 Received: from 1i5t5.duncan by ip68-231-15-181.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Jun 2007 00:38:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: [RFC] Non-Dev Contributors and the Tree Date: Thu, 7 Jun 2007 22:38:11 +0000 (UTC) Message-ID: References: <4667EF71.9010103@gentoo.org> <200706071650.54612.philantrop@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Reply-to: gentoo-dev@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-15-181.ph.ph.cox.net User-Agent: Pan/0.131 (Ghosts: First Variation) Sender: news X-Archives-Salt: 26577058-619f-44e1-a759-383d94bcfbb0 X-Archives-Hash: 6984f8b1bd8a62c39e48741d8dfbe650 "Wulf C. Krueger" posted 200706071650.54612.philantrop@gentoo.org, excerpted below, on Thu, 07 Jun 2007 16:50:54 +0200: > I mostly agree with your arguments but seeing what we have in the > Sunrise overlay I don't think we need another one. > > Today, people can get involved by submitting ebuilds to (and maintaining > them in) Sunrise rather easily. As easily as devs can take ebuilds from > there and add them to the official tree. > > What would/should be different compared to that if we implemented your > suggestion? The difference, as I read the proposal, is that while Sunrise is about packages that are /not/ in the main tree yet (if it's moved to the tree, it's out of sunrise, tho it might move to another overlay if appropriate), this proposal would extend that to packages that are in the tree as well. (Vetted) users could commit to in-tree packages, but only in the (main) development overlay. It'd be Sunrise, but just as devs watch what's going on there with the eventual goal of getting some of the ebuilds into the tree, so here, devs would watch and make commits to the (mirrored) tree from the development overlay. I've not read the rest of the responses yet, but the question I had was... OK, but won't that result in either (a) developers getting /more/ bump/test/grind, not less, since more of it would be taking commits already made by users and applying them to the mirrored tree (the committing users get more of the creativity, the devs end up being just shuttle monkeys, vetting then shuttling from the dev tree to the mirrored tree), or (b) the mirrored tree eventually falling seriously behind? IMO there may need to be mechanisms to prevent it from going one way or the other, as I don't otherwise see the proposed situation of dev then mirrored tree as being stable over time -- it'll lean toward a or b above. -- 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 -- gentoo-dev@gentoo.org mailing list