[openib-general] [PATCH] for OFED 1.2

[Michael S. Tsirkin]

Lot's of stuff *is* in wiki already - did you look at pages Vlad created?
Things can always be improved, you can add stuff too.


Quoting Jeff Squyres <jsquyres at cisco.com>:
Subject: Re: [PATCH] for OFED 1.2

It would be great if all of this knowledge is posted to the wiki to  
avoid repeating this conversation in the future (or one of countless  
variations of this conversation).  For example, I admit to not paying  
close attention to many of the threads on this list, but this was the  
first time I'd head of "quilt".

Specifically: if there are tools and methods that are helpful for OFA/ 
OFED development, they should be detailed on the wiki.  The wiki is  
where all permanent knowledge should be posted.

This is just my $0.000001...



On Feb 27, 2007, at 12:31 PM, Michael S. Tsirkin wrote:

>> Quoting Steve Wise <swise at opengridcomputing.com>:
>> Subject: Re: [openib-general] [PATCH] for OFED 1.2
>>
>> On Tue, 2007-02-27 at 18:55 +0200, Michael S. Tsirkin wrote:
>>>> Quoting Sean Hefty <sean.hefty at intel.com>:
>>>> Subject: Re: [PATCH] for OFED 1.2
>>>>
>>>>> Please send patches that will be added to kernel_patches/fixes.
>>>>>
>>>>> Please update your git tree from
>>>>> git://git.openfabrics.org/~vlad/ofed_1_2/.git  ofed_1_2
>>>>
>>>> You want me to create a patch that adds a file that contains the  
>>>> actual patches?
>>>>
>>>> Why not apply the patches directly?
>>>
>>> That's the ofed structure, this was discussed multiple times  
>>> already.
>>> The point is to keep all changes to upstream components separate,
>>> to make updating to upstream kernel trivial in the future.
>>>
>>> Worked quite well for OFED 1.1 -> 1.2 transition.
>>>
>>
>> Having these patches as files is painful for every developer because
>> they cannot create a patch against ofed_1_2/drivers/infiniband/*  
>> nor the
>> kernel.org upstream tree.
>
> Did you try using quilt which makes managing patch stacks quite easy?
> If you have quilt installed, OFED scripts actually use it
> to apply patches, so things are easy.
>
>> They need to apply all the current patches
>> and then create a patch on top of that. Or hope the patch applies
>> fuzzily.
>
> One point I can't stress enough: whatever way you create a patch,
> developers are expected to build and test it in OFED environment
> before posting.
>
>> I think with stacked git or just git and rebasing at key times, you
>> could keep an ofed_1_2 tree that folks can easily apply patches to...
>>
>> Its too late to change this for 1.2, but you might want to reconsider
>> the design for 1.3.
>
> Well, I experimented with git rebase and it is unfortunately still
> fragile at this point.
>
> I agree using stacked git might be a good idea, I just did not
> have the chance to experiment with it enough. I had an impression
> that publishing stg managed branch creates problems for whoever
> attempts to track it, but I might be wrong.
>
>
> -- 
> MST
>
> _______________________________________________
> openib-general mailing list
> openib-general at openib.org
> http://openib.org/mailman/listinfo/openib-general
>
> To unsubscribe, please visit http://openib.org/mailman/listinfo/ 
> openib-general


-- 
Jeff Squyres
Server Virtualization Business Unit
Cisco Systems


_______________________________________________
openib-general mailing list
openib-general at openib.org
http://openib.org/mailman/listinfo/openib-general

To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general

-- 
MST