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

[Amit Shah <amit.shah@redhat.com>]

On (Thu) Sep 10 2009 [19:19:03], Reimar Döffinger wrote:
> 
> 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 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:

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 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.

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 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.

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