[ewg] Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits

[Michael S. Tsirkin]

> Quoting Sean Hefty <mshefty at ichips.intel.com>:
> Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
> 
> >Here's a short list off the top of my head
> >
> >- A single git pull merges any number of backport changes
> >- A single git reset ORIG_HEAD recovers from a conflicting merge
> >- A single tag tags all code for all kernels
> >- On update from upstream, if there is a conflict
> >  between upstream code and and a patch
> >  it's easy to temporarily remote the patch, complete the merge,
> >  and go bugger the patch author
> >- For recent kernels there are almost no patches.
> >  So an update from upstream for these kernels is free,
> >  with branches I will still need to update all branches.
> >- Adding a fix which only affects common code
> >  is currently straight-forward: make a change, commit.
> >  With multiple branches every fix must be pulled into
> >  all branches.
> 
> You seem to be overlooking the fact that you already require a script to 
> check that things work for all kernels.  Until you apply a series of 
> patches to form a particular kernel, you don't know if a change that you 
> pulled in caused a conflict.  You still have the requirement to verify 
> the fix on all kernels, and it still requires running a script that 
> pushes/pops patches to create each tree.

Yes. But I find it preferable to manage history with
full power of native git tools, where a single hash identifies a revision,
and limit the scope of the scripts to the build process.

This, as opposed to an elaborate methodology that is based
on naming conventions, and requires use of scripts to do
basic tasks such as tagging, history rewriting, etc.

-- 
MST