[Freeipa-devel] Proposed standard for Patches: RFC

[Adam Young]

On 10/26/2010 03:29 PM, Simo Sorce wrote:
> On Tue, 26 Oct 2010 14:22:01 -0400
> Adam Young<ayoung at redhat.com>  wrote:
>
>    
>> 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.
>>      
> If the problem is tracking which patches have been applied an which are
> needed wouldn't it be easier instead if each developer published an
> official tree with the patches he proposes for inclusion ?
>
> That way all you need to do is a git log origin/master..dev_tree and
> you have all pending patches and the order they are applied to.
>
> Looks to me *much* handier then trying to order them based on file
> names and arbitrary sequence numbers.
>    

I'll admit this would be useful, but it would be another process that we 
don't have now, that I was trying to avoid.  We all have git repos on 
fedorapeople.  The trick is to deal with patches that have to get 
changed prior to commit, hence the numbering of -2 -3 after the seq number.

Really, the seq number is not needed, but makes a nice ready shorthand 
for the patch.  Pavel, Endi and I often refer to patches by number, like 
"your patch 0019"  which makes it handy.  The increasing seq approach to 
detect a missing packet works in TCP, so why not for us?



>    
>>>> 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.
>>      
> bugzilla numbers flies around the 600k mark, looks pretty easy to tell
> which is which unless we have a sudden, dramatic spike in tickets
> filed against the trac instance :)
>    
Yeah, but the full URL approach is self documenting.

> Simo.
>
>