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

[Blue Swirl]

On Thu, Sep 10, 2009 at 8:19 PM, Reimar Döffinger
<address@hidden> 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 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.

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.

submitting_patches.diff
Description: plain/text