On Thu, Sep 10, 2009 at 8:19 PM, Reimar Döffinger wrote: > On Thu, Sep 10, 2009 at 07:46:23PM +0300, Avi Kivity wrote: >> On 09/10/2009 07:38 PM, Anthony Liguori wrote: >> > Well the question is, should I/you edit this, or reject the patch >> > requesting a better changelog? >> > >> > Certainly, the later is what akpm often does. >> >> I'm happy to reject patches for whitespace but I will edit changelogs. >> My rationale is that many people don't care about that and I can't make >> them care; further the log is mostly for my own benefit - I spend quite >> a lot of time reading it when hunting regressions or preparing >> patchqueues for upstream. > > 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). > I am sure it misses a lot of stuff and there might even be objections to > 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: > > 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 possible > 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 start 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 should in an > understandable and not too verbose way describe what change was made and > why. > Also do not forget to add the appropriate Signed-off-by lines. > Do not expect an immediate reply to your patches, reacting to patches simply > 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. 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.