[Freeipa-devel] Proposed standard for Patches: RFC

Adam Young ayoung at redhat.com
Wed Oct 27 13:33:38 UTC 2010


On 10/26/2010 04:47 PM, Simo Sorce wrote:
> On Tue, 26 Oct 2010 16:26:13 -0400
> Adam Young<ayoung at redhat.com>  wrote:
>
>    
>> 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.
>>      
> Not sure what's the problem here, if I rebase a patch you have the
> latest one in my tree, no need to look for -1 -2 -3 as you can't be
> wrong if you re-fetch from my tree.
>    

Yes, and if we go with a Git based appraoch, that would be fine.  But 
the team seems to havea preference and a system in place that works with 
straight patches.  I am not trying to change that.  If you are set on a 
Git based approach, it is a more significant change from our current 
process, something that I would not advocate this close to a major release.

I'm just trying to codify what Rob, Endi and I are already doing, and 
which seems to work well.

>    
>> 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?
>>      
> Because I am not a machine :)
>    

I disagree.  So does schoolhouse rock:
http://www.youtube.com/watch?v=Kdn0pPcTvN4

> I see we constantly fail at correctly numbering sequentially stuff,
> from new error numbers to OIDs and other stuff, so I do not see this as
> a big improvement. I am not saying people shouldn't use this method if
> so they prefer, but mandating it seems a bit too much.
>    
It seems to be easy enough to do.

> Of course if others strongly feel this is the way to go, I will (try to)
> comply.
>    

Let's give it a go  for a few.

> Simo.
>
>    




More information about the Freeipa-devel mailing list