[Freeipa-devel] Proposed standard for Patches: RFC

[Adam Young]

On 10/26/2010 02:08 PM, Simo Sorce wrote:
> On Tue, 26 Oct 2010 13:40:11 -0400
> Adam Young<ayoung at redhat.com>  wrote:
>
>    
>> We've been doing this informally for a while, and I think, if we all
>> agree to the format, it will help keep track of patches, ACKs, and
>> commits.
>>
>>
>> 1.  Patch naming
>> Example patch name:
>> edewata-freeipa-0019-Certificate-management-for-services.patch
>>
>>
>> Format:  username-project-seq[-update]-description.extension
>>
>> username:  Your Fedora account name.
>> project name:   always 'freeeipa'
>>      
> Are these really necessary ?
> We have the name of the author in the patch anyway, and freeipa
> (with 2 'e's not 3 :-P) seem really redundant.
>    

Otherwise, we get into a conflict over who''s patch 519 it is, and we 
have no way to order it.

We've had enough issues where patch 11 requires patch 10 that it is just 
cleaner to try to apply all patches from a given developer in order.

I have a simple script that does the rename.  John Dennis has a more 
extensive one.  We can make this easy for you.

http://adam.younglogic.com/2010/09/preparing-patches-for-submission-to-the-freeipa-mailing-list/

> Bottomline I am lazy and would prefer not to have to rename patches
> after git format-patch creates them.
>
> So I'd like to understand the rationale for this format.
> After all we always send patches as attachments to emails, where we can
> explain what is going on.
>
>    
>> seq:  sequnece number.  please try to not skip numbers, as we will
>> use this number to ensure all patches from a given contributor get
>> reviewed. update.  If a patch requires modifications and additional
>> prior to submisiion, append a number starting at 2 and increasing by
>> one for each update.  Thus, if the above patch required additional
>> changes, the first would be:
>>       edewata-freeipa-0019-2-Certificate-management-for-services.patch
>>       and then
>>       edewata-freeipa-0019-3-Certificate-management-for-services.patch
>>
>> description:  This is the first line of the git commit, and should be
>> less than six words long (idealy two or three).  git format patch
>> will translate this line into the subject of the patch, with hyphens
>> replacing the whitespace.
>>
>> extension:  always .patch
>>
>>
>> 2. Patch format:
>> All patches should be in format to apply with
>>        'git am'.
>> This is produced from a git repository using the command
>>      'git format-patch'
>>
>>
>> If a patch addresses a ticket in Trac, the second line of the commit
>> should be the URL to track with the Ticket number.  For example:
>> https://fedorahosted.org/freeipa/ticket/339
>>      
> This part is worth, but I think we should require only the bug number
> and have the full URL as a nice optional.
>    
I just copy and paste from the browser.  It does make it clear whether 
we are talking about Trac or Bugzilla.


> Simo.
>
>