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 1HwgFQ-0000rs-G3 for garchives@archives.gentoo.org; Fri, 08 Jun 2007 15:19:33 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.14.0/8.14.0) with SMTP id l58FHtjD001304; Fri, 8 Jun 2007 15:17:55 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 l58FDalV027179 for ; Fri, 8 Jun 2007 15:13:36 GMT Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 0ED1C64816 for ; Fri, 8 Jun 2007 15:13:35 +0000 (UTC) X-Virus-Scanned: amavisd-new at gentoo.org X-Spam-Score: 0.409 X-Spam-Level: X-Spam-Status: No, score=0.409 required=5.5 tests=[AWL=-0.921, RCVD_NUMERIC_HELO=1.253, TW_IU=0.077] 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 KJliV6jlGYt0 for ; Fri, 8 Jun 2007 15:13:32 +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 4EA6764767 for ; Fri, 8 Jun 2007 15:13:30 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1Hwg2K-0005nW-H7 for gentoo-dev@gentoo.org; Fri, 08 Jun 2007 17:06:00 +0200 Received: from 82.152.204.56 ([82.152.204.56]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Jun 2007 17:06:00 +0200 Received: from slong by 82.152.204.56 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 08 Jun 2007 17:06:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Steve Long Subject: [gentoo-dev] Re: [RFC] Non-Dev Contributors and the Tree Date: Fri, 08 Jun 2007 15:39:34 +0100 Message-ID: References: <4667EF71.9010103@gentoo.org> <8cd1ed20706080001g3a58b15ej3ef9fe67d143d80d@mail.gmail.com> 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=us-ascii Content-Transfer-Encoding: 7Bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: 82.152.204.56 User-Agent: KNode/0.10.4 Sender: news X-Archives-Salt: 6be6ba92-994d-42da-b122-cc97b30aca5a X-Archives-Hash: 96c9ac25e77816e6895aff6b3f629512 Kent Fredric wrote: >> Comments? >> ~mcummings >> > As a non-dev with not a lot of free time, I applaud this suggestion. > However, my core fear is the potential for it becoming subject to > abuse, and people insisting on repeatedly uploading patches that are > not actually wanted / necessary for the project, despite the package > maintainer saying 'dude , stop' > Well presumably if the maintainer has said it in bugzilla/ whichever tracking mechanism you use, then it's on record. If it's transparent, it's hard for people to argue about it other than on the merits. And users and devs share a common interest in getting the software working optimally. > Basically, if a non-maintainer wants maintenance rights, how do they > go about attaining them? , an automated service, or some vetting > process? > Dunno what the procedure might end up becoming, but my understanding is commit right to the sunrise overlay, from where a dev has to commit it to the main tree. It seems like a logical extension of sunrise, and i am sure there are stats on who has submitted what to sunrise in the past. So there is a baseline for whom to invite to become s. > How do we go about handling the problem with the predicted increase in > collisions? > I guess it depends on what the predicted increase would be. Maybe one of the infra bods can enlighten us? (I'm guessing you'd take the writes of the users automatically selected and see how many collisions there would have been with the ebuilds they contributed to. A patch that got accepted wouldn't count, of course, if it were possible to track same,) > Is CVS fast enough / flexible enough for such a massive change in users? > > (forgive me if I've made a misunderstanding, but im a SVN man, not a > CVS'er ) > Well aiui CVS is a lot less resource-intensive than SVN and additionally the proposal was to utilise existing infra slightly differently. It doesn't sound like more workload for the servers involved. TBH it sounds more like the kernel model than anything; each individual is responsible for the commits they make with their signature. If they have come from elsewhere is irrelevant (apart from a legal viewpoint.) Code responsibility lies with one, when one presses send. kk or -- gentoo-dev@gentoo.org mailing list