From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from static.26.116.47.78.clients.your-server.de ([78.47.116.26] helo=phalanx.drlauer-research.com) by linuxtogo.org with esmtp (Exim 4.69) (envelope-from ) id 1OoyCQ-0004DZ-Er for openembedded-devel@lists.openembedded.org; Fri, 27 Aug 2010 14:38:27 +0200 Received: from [192.168.1.15] (e180147188.adsl.alicedsl.de [85.180.147.188]) by phalanx.drlauer-research.com (Postfix) with ESMTP id 05F97584627 for ; Fri, 27 Aug 2010 14:42:20 +0200 (CEST) From: "Dr. Michael Lauer" To: openembedded-devel@lists.openembedded.org In-Reply-To: References: Organization: Vanille-Media Date: Fri, 27 Aug 2010 14:37:59 +0200 Message-ID: <1282912679.1860.9.camel@jupiter> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 X-SA-Exim-Connect-IP: 78.47.116.26 X-SA-Exim-Mail-From: mickey@vanille-media.de X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on discovery X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 X-SA-Exim-Version: 4.2.1 (built Wed, 25 Jun 2008 17:20:07 +0000) X-SA-Exim-Scanned: Yes (on linuxtogo.org) Subject: Re: [RFC] review process X-BeenThere: openembedded-devel@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list Reply-To: openembedded-devel@lists.openembedded.org List-Id: Using the OpenEmbedded metadata to build Distributions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Aug 2010 12:38:27 -0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Am Freitag, den 27.08.2010, 14:15 +0200 schrieb Frans Meulenbroeks: > 1. If a patch does not get any review feedback in X weeks time; it is > ok to apply it. People who need more time to review a patch can > mention that in a short reply. In that case they are granted Y more > weeks to review. > (suggestion: X = Y = 2) > 2. If someone NAKs a patch it is obligatory to provide an explanation > why the patch is not good. > Rationale is that > a) people can fix the problem seen by the reviewer > b) people learn from it > c) if there is a disagreement it can be discussed (and if needed > raised to the TSC) > 3) NAKs that are not motivated/explained can be ignored as not given. > > Your feedback, suggestions, additions, amendments, whatever is appreciated. I agree with that. If someone does the work to create a patch he thinks is worthwhile to apply the least we can do when NAKing is to explain why it is not a good idea. :M: