From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mmryf-00086F-DQ for qemu-devel@nongnu.org; Sun, 13 Sep 2009 12:31:01 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mmrya-0007zW-IG for qemu-devel@nongnu.org; Sun, 13 Sep 2009 12:31:00 -0400 Received: from [199.232.76.173] (port=50246 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mmrya-0007zH-Bd for qemu-devel@nongnu.org; Sun, 13 Sep 2009 12:30:56 -0400 Received: from mail-ew0-f221.google.com ([209.85.219.221]:38345) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mmrya-0005iV-2N for qemu-devel@nongnu.org; Sun, 13 Sep 2009 12:30:56 -0400 Received: by ewy21 with SMTP id 21so2210553ewy.8 for ; Sun, 13 Sep 2009 09:30:55 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4AAD1364.40801@redhat.com> References: <4AA7A6EC.10907@codemonkey.ws> <4AA92122.3050103@codemonkey.ws> <4AA924AE.8060807@redhat.com> <4AA927D8.7000900@codemonkey.ws> <4AA92ADF.80003@redhat.com> <4AA92B7A.7010304@codemonkey.ws> <4AA92D5F.9070205@redhat.com> <20090910171903.GA16143@1und1.de> <4AAD1364.40801@redhat.com> From: Blue Swirl Date: Sun, 13 Sep 2009 19:30:35 +0300 Message-ID: Subject: Re: [Qemu-devel] [PATCH] [RESEND2] Qemu unmaintained? Content-Type: text/plain; charset=UTF-8 List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Amit Shah , Mark McLoughlin , Bernhard Kauer , qemu-devel@nongnu.org On Sun, Sep 13, 2009 at 6:44 PM, Avi Kivity wrote: > On 09/12/2009 08:55 AM, Blue Swirl wrote: >> >> We had a discussion about this earlier this year: >> http://lists.gnu.org/archive/html/qemu-devel/2009-04/msg01184.html >> >> Since that we have switched to git, so a lot of it could be >> simplified. Instead of the lengthy formatting specification, we could >> just require that the patch should apply with "git-am" to git HEAD >> without any editing, merging or even apply.whitespace=fix. >> > > That doesn't tell people what information to include, and if they don't care > how the log looks like, they'll do the minimum amount of work to make git am > like it. 1. Format of e-mail subject [clip] SP1.3: The summary must be suitable for changelog as is (start with a capital letter etc.) after deleting the bracketed text, white space after it and any text preceding it [clip] 2. Format of e-mail body [clip] SP2.2: The patch description must be selfstanding (not depend on other patches, other messages or background discussion) What information should people include? Description of the problem, step-by-step description how to reproduce it and the solution for the problem? Brief analysis of the alternative solutions considered so that if the commit is found buggy, corrective action is easier because we can try one of the alternatives instead of reverting? Link to hardware manual chapter where the correct behaviour is described?