From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Mm5Pk-00037T-PS for qemu-devel@nongnu.org; Fri, 11 Sep 2009 08:39:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Mm5Pf-00033U-6A for qemu-devel@nongnu.org; Fri, 11 Sep 2009 08:39:43 -0400 Received: from [199.232.76.173] (port=51491 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Mm5Pd-000337-TC for qemu-devel@nongnu.org; Fri, 11 Sep 2009 08:39:38 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4078) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mm5Pc-00059q-E1 for qemu-devel@nongnu.org; Fri, 11 Sep 2009 08:39:37 -0400 Date: Fri, 11 Sep 2009 18:09:06 +0530 From: Amit Shah Subject: Re: [Qemu-devel] [PATCH] [RESEND2] Qemu unmaintained? Message-ID: <20090911122220.GA8478@amit-x200.redhat.com> References: <20090910070336.GD3351@amit-x200.redhat.com> <4AA90592.7080100@codemonkey.ws> <4AA90F7F.2030709@redhat.com> <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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20090910171903.GA16143@1und1.de> Content-Transfer-Encoding: quoted-printable List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity , Anthony Liguori , Mark McLoughlin , Bernhard Kauer , qemu-devel@nongnu.org On (Thu) Sep 10 2009 [19:19:03], Reimar D=F6ffinger wrote: >=20 > I'd also add that anyone used to projects using SVN will probably be > used to writing only a general explanation of the patch while the real > commit message is left to whoever commits it. Maybe they ideally should > be identical, but I expect that quite a few people _won't_ expect their > email to appear 1:1 in the repository as log message (I usually feel > quite embarrassed when my hastily written email by which I only wanted > to get first comments ends up in a project's permanent history). So perhaps your "SUBMITTING_PATCHES" file should mention that the patch descriptions should be as good as possible, and mention: - what's being fixed - why it's being fixed the way it is - how does it solve the problem that's being fixed all of these reduce the load on maintainers and reviewers. If you took time out to write a patch and better some piece of code, you should take the time to tell why you spent so much time on it. > I am sure it misses a lot of stuff and there might even be objections t= o > some parts, but I wrote this draft of a "PATCHES" (or "CONTRIBUTING" or > whatever) file that might help newcomers (and even some long-term > developers might not know all the unwritten rules ;-). > Suggested text: One general comment: Please include line breaks between paragraphs. That makes things much easier to read. > This is a (very) rough guide on how to submit patches to qemu, what is = expected > of you and what to expect from the process. > Patches should go to the qemu-devel@nongnu.org list, subscription is po= ssible > via http://lists.nongnu.org/mailman/listinfo/qemu-devel > The subject for any emails containing patches should start with [PATCH]= so it is > obvious that there is a patch included. > Whenever you send a new patch or a new version of a patch, you should s= tart a new > thread - i.e. do _not_ reply to any email but write a new one. > Patches are preferred inline (i.e. not as attachments - but be careful = your mailer > does not mangle them e.g. by adding line breaks). > Emails generated via "git format-patch" are even better. > Also be aware that emails are often used as-is as log messages, so try = to write > your emails in a way that is suitable for this, in particular they shou= ld in an > understandable and not too verbose way describe what change was made an= d > why. You could add the points I mentioned above here. > Also do not forget to add the appropriate Signed-off-by lines. An example here wouldn't hurt. > Do not expect an immediate reply to your patches, reacting to patches s= imply > takes some time. If there is no reaction and you checked that the patch= was > not already applied (there currently is no notification about this) try= sending > the patch once again, it might just have got lost or forgotten at some > point. Please mention the commits-list where notifications are sent when patches get applied to the master branch of the git tree. Also mention Anthony's staging queue URL if someone really wants to know if their patch has been picked up by a bot for testing. In addition to the linefeed comment I gave above, the above list could be separated by bullets (since it is a list). Also, please make the text fit in 80 columns. And send it as a patch so that it's easy to apply. :-) Amit