[Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 187 bytes --]

Hi,

I gathered a few common complaints about patch submission, hopefully
not too much affected by my consumption of small amounts of various
alcoholic substances.

Comments, objections?

[-- Attachment #2: submitting_patches.diff --]
[-- Type: plain/text, Size: 4169 bytes --]

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Avi Kivity]

Blue Swirl wrote:
> Hi,
>
> I gathered a few common complaints about patch submission, hopefully
> not too much affected by my consumption of small amounts of various
> alcoholic substances.
>
>   
> +
> +SP2.3: The description must be followed by one blank line and a
> +"Signed-off-by:" line

A signoff is more than a format; it is a legal declaration, see the 
Linux Documentation/SubmittingPatches.  It should be clear to the 
submitter that this is so.

IIRC, one of the requirements is to use your real name :)

>
> +
> +SP3.2: If possible, please send the patch inlined (to make commenting
> +easier) and also attached (to make it easier to apply)

If the patch is attached (and not inlined) it should be marked as 
text/plain content type.

>
> +
> +SP4.4: The patches targeted for development branch must be based on
> +the current development repository
> +
> +SP4.5: The patches targeted for stable branch must be based on the
> +current stable repository

Suggest instead: patches should state which branch they are based on, 
and should be based on a recent version of the branch.

In addition:

When sending multiple patches, patches should be numbered (inside the 
brackets: [PATCH 09/17]) and should include a cover letter describing 
the patchset in general (as opposed to infividual patch descriptions).  
Patch management utilities (git send-email, quilt, and similar) can do 
this, so their use is recommended.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Blue Swirl]

[-- Attachment #1: Type: text/plain, Size: 1886 bytes --]

On 4/19/09, Avi Kivity <avi@redhat.com> wrote:
> Blue Swirl wrote:
>
> > Hi,
> >
> > I gathered a few common complaints about patch submission, hopefully
> > not too much affected by my consumption of small amounts of various
> > alcoholic substances.
> >
> >  +
> > +SP2.3: The description must be followed by one blank line and a
> > +"Signed-off-by:" line
> >
>
>  A signoff is more than a format; it is a legal declaration, see the Linux
> Documentation/SubmittingPatches.  It should be clear to the
> submitter that this is so.

I added this to a new section together with the licensing stuff.

>  IIRC, one of the requirements is to use your real name :)

I can't find such a requirement :)

> > +
> > +SP3.2: If possible, please send the patch inlined (to make commenting
> > +easier) and also attached (to make it easier to apply)
> >
>
>  If the patch is attached (and not inlined) it should be marked as
> text/plain content type.

Added.

> > +
> > +SP4.4: The patches targeted for development branch must be based on
> > +the current development repository
> > +
> > +SP4.5: The patches targeted for stable branch must be based on the
> > +current stable repository
> >
>
>  Suggest instead: patches should state which branch they are based on, and
> should be based on a recent version of the branch.

I'd suppose most of the patches are for the development branch, so one
of the subject tags could be "STABLE" indicating stable branch.
Without it dev branch is assumed.

>  In addition:
>
>  When sending multiple patches, patches should be numbered (inside the
> brackets: [PATCH 09/17]) and should include a cover letter describing the
> patchset in general (as opposed to infividual patch descriptions).  Patch
> management utilities (git send-email, quilt, and similar) can do this, so
> their use is recommended.

I collected the patch series stuff to a new section.

[-- Attachment #2: submitting_patches.diff --]
[-- Type: plain/text, Size: 4826 bytes --]

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Andreas Färber]

Am 19.04.2009 um 18:59 schrieb Blue Swirl:

> On 4/19/09, Avi Kivity <avi@redhat.com> wrote:
>> Blue Swirl wrote:
>>
>>> Hi,
>>>
>>> I gathered a few common complaints about patch submission, hopefully
>>> not too much affected by my consumption of small amounts of various
>>> alcoholic substances.
>
>>> +
>>> +SP4.4: The patches targeted for development branch must be based on
>>> +the current development repository
>>> +
>>> +SP4.5: The patches targeted for stable branch must be based on the
>>> +current stable repository
>>>
>>
>> Suggest instead: patches should state which branch they are based  
>> on, and
>> should be based on a recent version of the branch.
>
> I'd suppose most of the patches are for the development branch, so one
> of the subject tags could be "STABLE" indicating stable branch.
> Without it dev branch is assumed.

4.5. -- I'd suspect that for most patches for STABLE it's not  
necessary to send them twice, once against the stable branch, when  
they can easily be cherry-picked or patch -p1'ed. Please consider  
"should" or "must ... if it differs from devel branch" there.

2.4 -- Do comments after --- line have to be space-indented or not for  
inline patches?

6.2 -- "as opposed to individual patch descriptions" may sound  
misleading, suggest "in addition to individual patch descriptions".

Andreas

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Anthony Liguori]

Andreas Färber wrote:
>
> 4.5. -- I'd suspect that for most patches for STABLE it's not 
> necessary to send them twice, once against the stable branch, when 
> they can easily be cherry-picked or patch -p1'ed. Please consider 
> "should" or "must ... if it differs from devel branch" there.

I consider all patches for the stable branch.  [STABLE] is just a hint 
as far as I'm concerned.  If a set of patches are too difficult to apply 
to the stable branch, I reserve the right to bounce the series, even for 
trunk, asking for two submissions but then again, if this ever happened, 
it suggests that either we need a new release (because things have 
changed too much since the last release) or that the patch probably 
shouldn't be in stable.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[M. Warner Losh]

In message: <f43fc5580904190959nbd0f92ev6a2932712aab179f@mail.gmail.com>
            Blue Swirl <blauwirbel@gmail.com> writes:
: >  IIRC, one of the requirements is to use your real name :)
: 
: I can't find such a requirement :)

For LEGAL documents and declarations, one must use one's real name.
The reasons for this are beyond the scope of this mailing list. :)

Warner

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Avi Kivity]

Blue Swirl wrote:
>> >  IIRC, one of the requirements is to use your real name :)
>>     
>
> I can't find such a requirement :)
>   

 From [1]:

> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=f309d3c6221c3699a0c0b97fbe689faed09e4d2f;hb=HEAD#l320>then you just add a line saying
>
> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=f309d3c6221c3699a0c0b97fbe689faed09e4d2f;hb=HEAD#l321> 
>
> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=f309d3c6221c3699a0c0b97fbe689faed09e4d2f;hb=HEAD#l322>        
> Signed-off-by: Random J Developer <random@developer.example.org>
>
> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=f309d3c6221c3699a0c0b97fbe689faed09e4d2f;hb=HEAD#l323> 
>
> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=f309d3c6221c3699a0c0b97fbe689faed09e4d2f;hb=HEAD#l324> 
> using your real name (sorry, no pseudonyms or anonymous contributions.)




>>  If the patch is attached (and not inlined) it should be marked as
>> text/plain content type.
>>     
>
> Added.
>   

Your own message has

--001485f87bbc990faa0467eb577c
Content-Type: plain/text; name="submitting_patches.diff"
Content-Disposition: attachment; filename="submitting_patches.diff"
Content-Transfer-Encoding: base64
X-Attachment-Id: f_ftpzesul


So my client won't display it inline :)

A local misconfiguration, or is plain/text legal?

>>  Suggest instead: patches should state which branch they are based on, and
>> should be based on a recent version of the branch.
>>     
>
> I'd suppose most of the patches are for the development branch, so one
> of the subject tags could be "STABLE" indicating stable branch.
> Without it dev branch is assumed.
>   

Right.

[1] 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=f309d3c6221c3699a0c0b97fbe689faed09e4d2f;hb=HEAD

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Blue Swirl]

On 4/20/09, Avi Kivity <avi@redhat.com> wrote:
> Blue Swirl wrote:
>
> >
> > > >  IIRC, one of the requirements is to use your real name :)
> > >
> > >
> >
> > I can't find such a requirement :)
> >
> >
>
>  From [1]:
>
>
> >
> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=f309d3c6221c3699a0c0b97fbe689faed09e4d2f;hb=HEAD#l320>then
> you just add a line saying
> >
> >
> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=f309d3c6221c3699a0c0b97fbe689faed09e4d2f;hb=HEAD#l321>
> >
> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=f309d3c6221c3699a0c0b97fbe689faed09e4d2f;hb=HEAD#l322>
>        Signed-off-by: Random J Developer <random@developer.example.org>
> >
> >
> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=f309d3c6221c3699a0c0b97fbe689faed09e4d2f;hb=HEAD#l323>
> >
> <http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/SubmittingPatches;h=f309d3c6221c3699a0c0b97fbe689faed09e4d2f;hb=HEAD#l324>
> using your real name (sorry, no pseudonyms or anonymous contributions.)
> >

OK, I looked at too old version (2.6.16) that had at hand.

> >
> > >  If the patch is attached (and not inlined) it should be marked as
> > > text/plain content type.
> > >
> > >
> >
> > Added.
> >
> >
>
>  Your own message has
>
>  --001485f87bbc990faa0467eb577c
>  Content-Type: plain/text; name="submitting_patches.diff"
>  Content-Disposition: attachment;
> filename="submitting_patches.diff"
>  Content-Transfer-Encoding: base64
>  X-Attachment-Id: f_ftpzesul
>
>
>  So my client won't display it inline :)
>
>  A local misconfiguration, or is plain/text legal?

I think it's a bug in gmail, I don't know if it can be configured.

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Avi Kivity]

Blue Swirl wrote:
>>  So my client won't display it inline :)
>>
>>  A local misconfiguration, or is plain/text legal?
>>     
>
> I think it's a bug in gmail, I don't know if it can be configured

A little experimenting showed that gmail derives attachment mime types 
from the browser.  On my system (firefox/linux) that is taken from 
/etc/mime.types.  Once I added diff and patch as text/plain, gmail 
attachments started to appear inline.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

[Qemu-devel] Re: [PATCH, RFC] Add file describing rules for submitting patches

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

Blue Swirl wrote:
> Hi,
> 
> I gathered a few common complaints about patch submission, hopefully
> not too much affected by my consumption of small amounts of various
> alcoholic substances.

Don't drink and patch. Oh, wait, this was: "Don't drink and derive!" So
this is probably ok.

> 
> Comments, objections?

SP3.2: If you only attach, pleeeease don't use base64 encoding etc. And
there should be no maintainer exception...

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Re: [PATCH, RFC] Add file describing rules for submitting patches

[M. Warner Losh]

In message: <49EB55D8.7020903@web.de>
            Jan Kiszka <jan.kiszka@web.de> writes:
: Blue Swirl wrote:
: > Hi,
: > 
: > I gathered a few common complaints about patch submission, hopefully
: > not too much affected by my consumption of small amounts of various
: > alcoholic substances.
: 
: Don't drink and patch. Oh, wait, this was: "Don't drink and derive!" So
: this is probably ok.
: 
: > 
: > Comments, objections?
: 
: SP3.2: If you only attach, pleeeease don't use base64 encoding etc. And
: there should be no maintainer exception...

How can you attach a patch with MIME and not do that?

Warner

Re: [Qemu-devel] Re: [PATCH, RFC] Add file describing rules for submitting patches

[Jan Kiszka]

[-- Attachment #1: Type: text/plain, Size: 907 bytes --]

M. Warner Losh wrote:
> In message: <49EB55D8.7020903@web.de>
>             Jan Kiszka <jan.kiszka@web.de> writes:
> : Blue Swirl wrote:
> : > Hi,
> : > 
> : > I gathered a few common complaints about patch submission, hopefully
> : > not too much affected by my consumption of small amounts of various
> : > alcoholic substances.
> : 
> : Don't drink and patch. Oh, wait, this was: "Don't drink and derive!" So
> : this is probably ok.
> : 
> : > 
> : > Comments, objections?
> : 
> : SP3.2: If you only attach, pleeeease don't use base64 encoding etc. And
> : there should be no maintainer exception...
> 
> How can you attach a patch with MIME and not do that?

Mime doesn't imply base64. Binary data enforces base64. Otherwise plain
7bit encoding is fine, and at least my probably rarely used mail client
is no longer skeptical about the printability of the attachment.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 257 bytes --]

Re: [Qemu-devel] Re: [PATCH, RFC] Add file describing rules for submitting patches

[Anthony Liguori]

M. Warner Losh wrote:
> In message: <49EB55D8.7020903@web.de>
>             Jan Kiszka <jan.kiszka@web.de> writes:
> : Blue Swirl wrote:
> : > Hi,
> : > 
> : > I gathered a few common complaints about patch submission, hopefully
> : > not too much affected by my consumption of small amounts of various
> : > alcoholic substances.
> : 
> : Don't drink and patch. Oh, wait, this was: "Don't drink and derive!" So
> : this is probably ok.
> : 
> : > 
> : > Comments, objections?
> : 
> : SP3.2: If you only attach, pleeeease don't use base64 encoding etc. And
> : there should be no maintainer exception...
>
> How can you attach a patch with MIME and not do that?
>   

If you tolerate MIME, you have to accept different encoding types 
(including base64).  Right now, just accepting text/plain and 
text/x-diff seems to work well enough.  The most common failure for my 
scripts wrt attachments is with mailers that do application/binary or 
some similarly opaque mime type.  What's particularly bad are mailers 
that send a plain text descriptions, HTML descriptions, and then the 
patch.  This last two categories are too difficult to handle correctly 
in scripts so that's where I want to bounce.  It's not a huge problem 
though.  It only happens in < %1 of patches.

Regards,

Anthony Liguori

> Warner
>
>
>   

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[M. Warner Losh]

In message: <f43fc5580904190832g413e67bn494f696a3e3279f4@mail.gmail.com>
            Blue Swirl <blauwirbel@gmail.com> writes:
: +SP2.4: Optionally, the "Signed-off-by:" line may be followed with a
: +line with only "---" and on the following lines, other comments not
: +intended for changelog (for example diffstat, location of a git tree,
: +whether the patch is also directed towards stable tree, witty
: +signature etc.)
: +
: +SP2.5: Exception: For extremely short and trivial patches (one-line
: +fixes etc.), the description and "Signed-off-by:" lines may be
: +omitted, in which case the subject must be appended with the
: +submitter's name in parenthesis

Signed-off-by: is at least an implied contract that the patch
submitted conforms to the Developer's Certificate of Origin 1.1:

        Developer's Certificate of Origin 1.1

        By making a contribution to this project, I certify that:

        (a) The contribution was created in whole or in part by me and I
            have the right to submit it under the open source license
            indicated in the file; or

        (b) The contribution is based upon previous work that, to the best
            of my knowledge, is covered under an appropriate open source
            license and I have the right under that license to submit that
            work with modifications, whether created in whole or in part
            by me, under the same open source license (unless I am
            permitted to submit under a different license), as indicated
            in the file; or

        (c) The contribution was provided directly to me by some other
            person who certified (a), (b) or (c) and I have not modified
            it.

        (d) I understand and agree that this project and the contribution
            are public and that a record of the contribution (including all
            personal information I submit with it, including my sign-off) is
            maintained indefinitely and may be redistributed consistent with
            this project or the open source license(s) involved.

At least that's what it means for the Linux world.  I believe that
QEMU also follows that, but we should likely make it explicit in this
document.

That's why trivial patches don't necessarily need this: There's no IP
associated with them, so no need to diligently track it.

Warner

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Anthony Liguori]

Blue Swirl wrote:
> Hi,
>
> I gathered a few common complaints about patch submission, hopefully
> not too much affected by my consumption of small amounts of various
> alcoholic substances.
>
> Comments, objections?
>   
> +SP2.5: Exception: For extremely short and trivial patches (one-line
> +fixes etc.), the description and "Signed-off-by:" lines may be
> +omitted, in which case the subject must be appended with the
> +submitter's name in parenthesis

Signed-off-by can never be omitted--even for one line fixes.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Avi Kivity]

Anthony Liguori wrote:
> Blue Swirl wrote:
>> Hi,
>>
>> I gathered a few common complaints about patch submission, hopefully
>> not too much affected by my consumption of small amounts of various
>> alcoholic substances.
>>
>> Comments, objections?
>>   +SP2.5: Exception: For extremely short and trivial patches (one-line
>> +fixes etc.), the description and "Signed-off-by:" lines may be
>> +omitted, in which case the subject must be appended with the
>> +submitter's name in parenthesis
>
> Signed-off-by can never be omitted--even for one line fixes.

Oh, and you don't need the author's name if we switch to git.

-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Blue Swirl]

On 4/20/09, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Blue Swirl wrote:
>
> >
> > Hi,
> >
> > I gathered a few common complaints about patch submission, hopefully
> > not too much affected by my consumption of small amounts of various
> > alcoholic substances.
> >
> > Comments, objections?
> >  +SP2.5: Exception: For extremely short and trivial patches (one-line
> > +fixes etc.), the description and "Signed-off-by:" lines may be
> > +omitted, in which case the subject must be appended with the
> > +submitter's name in parenthesis
> >
>
>  Signed-off-by can never be omitted--even for one line fixes.

I disagree. Changes that are small enough do not create any
copyrightable material, thus they may come from any source.

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Anthony Liguori]

Blue Swirl wrote:
> On 4/20/09, Anthony Liguori <anthony@codemonkey.ws> wrote:
>   
>> Blue Swirl wrote:
>>
>>     
>>> Hi,
>>>
>>> I gathered a few common complaints about patch submission, hopefully
>>> not too much affected by my consumption of small amounts of various
>>> alcoholic substances.
>>>
>>> Comments, objections?
>>>  +SP2.5: Exception: For extremely short and trivial patches (one-line
>>> +fixes etc.), the description and "Signed-off-by:" lines may be
>>> +omitted, in which case the subject must be appended with the
>>> +submitter's name in parenthesis
>>>
>>>       
>>  Signed-off-by can never be omitted--even for one line fixes.
>>     
>
> I disagree. Changes that are small enough do not create any
> copyrightable material, thus they may come from any source.
>   

It's not just an issue of copyright.  It's also a statement that you are 
allowed to be submitting patches to a given project.  Before DCO, some 
projects used to require forms from employers stating that contributions 
were allowed because some employers have non-compete contracts that 
would prevent an employee from working on a project.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Anthony Liguori]

Blue Swirl wrote:
> Hi,
>
> I gathered a few common complaints about patch submission, hopefully
> not too much affected by my consumption of small amounts of various
> alcoholic substances.
>
> Comments, objections?
>   

> +SP4.1: It must be possible to apply the patch with quilt (equivalent
> +to patch -p1) and "git am" without any editing or extra flags

svn diff generates -p0 patches so both -p1 and -p0 should be accepted.

Regards,

Anthony Liguori

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Blue Swirl]

On 4/20/09, Anthony Liguori <anthony@codemonkey.ws> wrote:
> Blue Swirl wrote:
>
> > Hi,
> >
> > I gathered a few common complaints about patch submission, hopefully
> > not too much affected by my consumption of small amounts of various
> > alcoholic substances.
> >
> > Comments, objections?
> >
> >
>
>
> > +SP4.1: It must be possible to apply the patch with quilt (equivalent
> > +to patch -p1) and "git am" without any editing or extra flags
> >
>
>  svn diff generates -p0 patches so both -p1 and -p0 should be accepted.

Quilt does not accept -p0 patches without extra work. Remember, the
idea is to reduce our burden, make it easier to test and apply
patches.

Diff can generate other types of diffs besides the unified type but we
don't want any other.

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Kevin Wolf]

Blue Swirl schrieb:
> On 4/20/09, Anthony Liguori <anthony@codemonkey.ws> wrote:
>> Blue Swirl wrote:
>>
>>> Hi,
>>>
>>> I gathered a few common complaints about patch submission, hopefully
>>> not too much affected by my consumption of small amounts of various
>>> alcoholic substances.
>>>
>>> Comments, objections?
>>>
>>>
>>
>>> +SP4.1: It must be possible to apply the patch with quilt (equivalent
>>> +to patch -p1) and "git am" without any editing or extra flags
>>>
>>  svn diff generates -p0 patches so both -p1 and -p0 should be accepted.
> 
> Quilt does not accept -p0 patches without extra work. Remember, the
> idea is to reduce our burden, make it easier to test and apply
> patches.

I think you'll survive the extra work of adding a -p0 to your series 
file from time to time. Currently SVN is the official solution of qemu 
and it's not obvious how you would create -p1 patches with svn diff. And 
nowadays most patches are generated with git anyway.

Kevin

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Blue Swirl]

On 4/20/09, Kevin Wolf <kwolf@redhat.com> wrote:
> Blue Swirl schrieb:
>
> > On 4/20/09, Anthony Liguori <anthony@codemonkey.ws> wrote:
> >
> > > Blue Swirl wrote:
> > >
> > >
> > > > Hi,
> > > >
> > > > I gathered a few common complaints about patch submission, hopefully
> > > > not too much affected by my consumption of small amounts of various
> > > > alcoholic substances.
> > > >
> > > > Comments, objections?
> > > >
> > > >
> > > >
> > >
> > >
> > > > +SP4.1: It must be possible to apply the patch with quilt (equivalent
> > > > +to patch -p1) and "git am" without any editing or extra flags
> > > >
> > > >
> > >  svn diff generates -p0 patches so both -p1 and -p0 should be accepted.
> > >
> >
> > Quilt does not accept -p0 patches without extra work. Remember, the
> > idea is to reduce our burden, make it easier to test and apply
> > patches.
> >
>
>  I think you'll survive the extra work of adding a -p0 to your series file
> from time to time. Currently SVN is the official solution of qemu and it's
> not obvious how you would create -p1 patches with svn diff. And nowadays
> most patches are generated with git anyway.

If (when?) we switch to git, references to quilt can be dropped and
the whole document can be made much shorter.

Supporting -p0 does not reduce maintainer burden (resulting in
valuable patches getting lost etc.). Making the submitter's life
easier is OK and nice, but that is secondary.

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[François Revol]

> > > I gathered a few common complaints about patch submission,
> > > hopefully
> > > not too much affected by my consumption of small amounts of
> > > various
> > > alcoholic substances.
> > >
> > > Comments, objections?
> > >
> > >
> >
> >
> > > +SP4.1: It must be possible to apply the patch with quilt
> > > (equivalent
> > > +to patch -p1) and "git am" without any editing or extra flags
> > >
> >
> >  svn diff generates -p0 patches so both -p1 and -p0 should be
> > accepted.
>
> Quilt does not accept -p0 patches without extra work. Remember, the
> idea is to reduce our burden, make it easier to test and apply
> patches.

Isn't it some opensource thingy ? Then you can fix it, right ?

I don't enjoy the perspective of taking the burden of switching from
svn to git just because of it.

François.

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Avi Kivity]

François Revol wrote:
> I don't enjoy the perspective of taking the burden of switching from 
> svn to git just because of it.
>   

Aren't we switching to git anyway?  Then all this will be moot.

I suggest writing these instructions to suit the new world order, not 
subversion.


-- 
error compiling committee.c: too many arguments to function

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Anthony Liguori]

Avi Kivity wrote:
> François Revol wrote:
>> I don't enjoy the perspective of taking the burden of switching from 
>> svn to git just because of it.
>>   
>
> Aren't we switching to git anyway?  Then all this will be moot.

I've got a working commit hook for generating emails (thanks to Avi).  I 
have to submit this as a ticket to Savannah to have it installed.  This 
can take anywhere from a day to a couple weeks depending on how busy 
they are.  I'm going to have the script send to a dedicated mailing list.

Once that is setup, I'll have the current git tree mirror SVN for a 
while.  Perhaps a few weeks?  Enough time to give the current mirrors 
time to switch over from doing git-svn to doing a straight git pull.

Then we'll do a flag day and shut down the SVN repo and start committing 
to git.

Regards,

Anthony Liguori

> I suggest writing these instructions to suit the new world order, not 
> subversion.
>
>

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Avi Kivity]

Anthony Liguori wrote:
>
> Once that is setup, I'll have the current git tree mirror SVN for a 
> while.  Perhaps a few weeks?  Enough time to give the current mirrors 
> time to switch over from doing git-svn to doing a straight git pull.
>

I recommend about 15 minutes.  It's not like the git mirrors are useful 
for anything once you have a git master.  If anyone uses a mirror, they 
should just switch to the main repository for less latency.

-- 
Do not meddle in the internals of kernels, for they are subtle and quick to panic.

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Anthony Liguori]

François Revol wrote:
> I don't enjoy the perspective of taking the burden of switching from 
> svn to git just because of it.
>   

Switching from svn->git is independent of this set of guidelines, but...

I really want it to happen and I believe that unless something has 
changed recently, it's going to happen in the near future.  For dealing 
with a project like QEMU, svn is actually pretty painful to work with.  
I've had to write a large number of scripts to simulate behavior similar 
to git whereas I can commit a large number of patches at once.  Of 
course, this isn't always perfect and if you watch the mailing list, 
you'll see that sometimes svn adds don't happen when they should.

This is just one of the many reasons to switch to git.

Regards,

Anthony Liguori

> François.
>
>
>   

Re: [Qemu-devel] [PATCH, RFC] Add file describing rules for submitting patches

[Anthony Liguori]

Blue Swirl wrote:
> On 4/20/09, Anthony Liguori <anthony@codemonkey.ws> wrote:
>   
>> Blue Swirl wrote:
>>
>>     
>>> Hi,
>>>
>>> I gathered a few common complaints about patch submission, hopefully
>>> not too much affected by my consumption of small amounts of various
>>> alcoholic substances.
>>>
>>> Comments, objections?
>>>
>>>
>>>       
>>     
>>> +SP4.1: It must be possible to apply the patch with quilt (equivalent
>>> +to patch -p1) and "git am" without any editing or extra flags
>>>
>>>       
>>  svn diff generates -p0 patches so both -p1 and -p0 should be accepted.
>>     
>
> Quilt does not accept -p0 patches without extra work. Remember, the
> idea is to reduce our burden, make it easier to test and apply
> patches.
>   

guilt does ;-)

FWIW, I'm working on getting the email commit script in place for the 
Savannah git repo.  That's the last bit needed to switch from svn -> git.

After that, a git-send-email requirement (or equiv) would make a lot of 
sense as it significantly reduces the maintainers work via git-am.

Regards,

Anthony Liguori

> Diff can generate other types of diffs besides the unified type but we
> don't want any other.
>
>
>