Re: [Qemu-devel] [PATCH] [RESEND2] Qemu unmaintained?

[Reimar Döffinger]

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 address@hidden 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.