From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1GCkoS-00049f-GM for mharc-grub-devel@gnu.org; Mon, 14 Aug 2006 18:21:36 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GCkoQ-00045n-RE for grub-devel@gnu.org; Mon, 14 Aug 2006 18:21:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GCkoO-000403-Dm for grub-devel@gnu.org; Mon, 14 Aug 2006 18:21:34 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GCkoO-0003zw-9l for grub-devel@gnu.org; Mon, 14 Aug 2006 18:21:32 -0400 Received: from [195.54.107.70] (helo=mxfep01.bredband.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GCkuH-0001p5-Uw for grub-devel@gnu.org; Mon, 14 Aug 2006 18:27:38 -0400 Received: from localhost.localdomain ([213.113.223.229] [213.113.223.229]) by mxfep01.bredband.com with ESMTP id <20060814222131.CDPZ5813.mxfep01.bredband.com@localhost.localdomain> for ; Tue, 15 Aug 2006 00:21:31 +0200 From: Johan Rydberg To: grub-devel@gnu.org Date: Tue, 15 Aug 2006 00:37:23 +0200 Message-ID: <871wrjhrks.fsf@night.trouble.net> User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: Let core developers "vote" to accept patches. X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Aug 2006 22:21:35 -0000 Hi, In other projects that I've worked on, we've used a system where the core developers can either give a +1 or a -1 on a contributed patch. If a patch receives two +1's or more, it is accepted (if there are no -1's) and committed by one of the developers. This lowers the pressure on the maintainers, and hopefully will speed up the development. Though, the core developers need to be a bit careful. They should not give +1's or -1's on a patch that they either (1) do not fully understand, or that (2) applies to a section of the code that they are not knowledgeable about. It is then better to either state that they do not know the area well enough, and maybe give the patch a +0, or be silent. The downside is that some developers will never feel that they are knowledgeable enough to comment on a contribution; resulting in that the maintainer will have to do it. The same situation we are in now, more or less. The upside is that the maintainers can focus on other things than just reviewing patches; maybe getting some new features in. Also, trivial and small patches will get quicker review and get merged into the tree in a swift manner. Please note: This is in no way an attempt to overrun any of our maintainers, it is just an attempt to make things go a bit smoother and faster in the times when the maintainers are busy with other things. Please note: I'm not saying I'm in any way a core developer, just sharing my experiences from other projects. Okuji, Marco, others; comments? ~j