[openib-general] [PATCH] for OFED 1.2

[Michael S. Tsirkin]

> 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