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

[Arthur Jones]

hi michael, ...

On Tue, Jul 24, 2007 at 08:52:20PM +0300, Michael S. Tsirkin wrote:
> > i'd _really_ like to see a list of the advantages of
> > patches over branches.  it's hard for me to know if
> > i'm just missing something if the case is not laid out...

thanks for the list...

> Here's a short list off the top of my head
> 
> - A single git pull merges any number of backport changes

ok, you can run one command instead of a 4-line
script.   hmm, i guess you could say this is a
very slight advantage to using patches...
 
> - A single git reset ORIG_HEAD recovers from a conflicting merge

handling conflicts is a big part of a maintainer's
job!  the _vast_ majority of the time i bet you already
know how to do the merge.  if you don't, then only
the backport branches which haven't merged yet are
stuck and you can pick up where you left off (which
is how i do it now).  but if you're stuck in some
strange intermediate state with some patches pushed
and some yet to push in the configure script, i could
see how you'd want to punt.  but, someone is doing
this work, and that someone almost certainly has a
difficult time reproducing and developing a stack of
patches..

if, though, you must have a pristine environment,
this is easily solved by using an intermediate repo:

git clone -s <canonical repo>
<run the pull>
<any conflicts, dump this guy, otherwise, pull this in>

i bet this is very similar time-wise to running the
merge, then the ofed_scripts/configure over all supported
branches.  merges in git are _fast_...

> - A single tag tags all code for all kernels

store commit ids in a file and tag that?

> - 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

i think this is easier with the backport branches,
see git clone -s above.  or, just fixup the error.
the reason you have to bugger the author may be that
you don't have the tools necessary to actually fix
up the patch -- but you can prob bet the author doesn't
like to fixup patches in quilt any more than you do...

> - 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.

i can say from a couple months experience that
upstream merges are "free" using backport branches.
running the script to reflow the branches is
_far_ less complex than the configure script,
has fewer dependencies and is much simpler to
maintain and understand.  also, if the upstream
changes touch code that conflicts with a backport
patch, you get to fix the problem as it happens
in a much more comfortable environment (i.e. you
don't need quilt)...

> - 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.

this use case is actually a good reason to
use backport branches.  with the patches,
you still need to fan out the changes to all
the backport branches.  but, in general, you
don't.  so you end up making a change and
_not realizing_ that it broke some random
backport patch.  by reflowing after every
change, you get to see it break right there
in front of you and you're way more likely
to know how to fix it.  you could do this
with the build script too, but that would
require a 4 line script -- and you'd need
to switch over to using quilt or some other
patch queue based system (yuck!)...

all your points above you made from the POV
of the maintainer.  but, what about the _users_
of the repo.  as long as changes are kept as
patches, trying to figure out what has
changed with your latest round of backports
comes down to recreating a tree and pulling
from that.  it's extremely fragile and error
prone.  there is only one maintainer, but many
developers.  if we can make their lives significantly
easier then it should be a net gain...

the backport branches make merging upstream changes
easier.  they make merging developer changes easier.
they make finding and fixing backport conflicts easier.
they make viewing and navigating changes easier.  but,
you need to use very short scripts (which i'm happy to
create and maintain) to tag and pull -- doesn't seem like
much of a price to pay to me...

arthur