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

[Michael S. Tsirkin]

>Quoting Arthur Jones <arthur.jones at qlogic.com>:
>Subject: Re: [ofa-general] ANNOUNCE ofed backports for 2.6.22 kernel bits
>
>hi michael, ...
>
>On Tue, Jun 12, 2007 at 11:41:08AM +0300, Michael S. Tsirkin wrote:
>> For whom it may concern,
>> I have created an ofed git tree updated with kernel bits from 2.6.22-rc4,
>> and put that up at git://git.openfabrics.org/~mst/ofed_kernel.git
>> [...] 
>> In particular, there were a ton of ipath patches that it seems were
>> for the most part applied.
>> Qlogic maintainers, please help double check that I did not miss something
>> of value.
>
>thanks for setting this up, i'm still looking
>at the diffs to make sure things got setup
>correctly for the ipath stuff...
>
>i have found it difficult to navigate the
>source having to run:
>
>./ofed_scripts/configure --kernel-version=2.6.xxx --without-quilt
>
>everytime to check against our tree.  so, rather
>than spending the better part of the afternoon
>running these scripts by hand, i created a shell
>script to populate a bunch of branches with the
>backports in each branch.
>
>at qlogic we now keep the backports as branches in
>our git tree and this, i find, is much easier to
>handle.  because:
>
>* viewing and navigating backport source becomes
>  _much_ easier.
>* merges are easier -- patches are much more fragile
>  than branches.
>* comparisons are easier -- checking for differences
>  between backports and between a backport and the
>  canonical source is faster and more convenient...
>* changesets are readable.  trying to decipher diffs
>  to patches is medically proven to take months, if not
>  years, off your life.

Sigh. I wish it were possible to do everything through
addons tricks.

I see the advantages of the "bush of branches" -
for example it's possible
to add a backport patch to a recent kernel, and then
merge this into other kernel branches.

But I also see a serious problem with addressing: basically
git tracks content. It's not designed to track a bush
of branches taken together.  For example, take tagging:
tag namespace is global, so you can not have the same
tag point at multiple branches at the same time.

>anyway, what do you think?  is there anyway i could
>convince you to dump the backport patches and put
>all the backports in branches?  i'm willing to do the
>legwork if you see value...

Can you publish the scripts and/or the tree?
I think we can start by just running the scripts nightly,
making it possible for people to view backport history
with gitview.

-- 
MST