stan wrote at 08:30 -0500 on Mar  2, 2009:
 > I really think we need to come up with a plan that results in it being
 > easier to comile clients on older machines. I have expressed my opinion
 > that this needs to be a forkof a 2.5 branch, but I did not seem to get much
 > in the way of buy in by others on this list ofr that. Does anyiine have a
 > better plan?

You never really said why you need to fork 2.5 as opposed
to just run 2.5.2 (or 2.4.5) on older clients.

Security fixes?
Specific features?

I think that putting security fixes onto a branch of 2.5 might be a
reasonable task.  Backporting some of the newer APIs would likely
be a good bit more work, and, depending on your point of view,
possibly not worth it.

That said, it's possible committers would be willing to entertain
committing patches to a 2.5.2 branch.  I can't speak for them, but if
the work is made minimal (by submitting well-documented patches), they
might be reasonable about it.  You could test the waters with a patch
to fix some buffer overflow and ask (on amanda-hackers) if they would
be willing to commit it.  Cutting a new release is probably beyond the
scope, but making commits to a legacy branch for a while seems
reasonable.

And if they don't, then you could, as you seem to be hinting, start a
fork yourself.  I can't say how popular it would be.  Personally, I've
had reasonable success getting the newer code to compile / run on
older machines, certainly for clients if not the server code.  It may
be less work than a fork (and patches possibly more acceptable to the
current maintainers).

But if you publish a fork (whether it be a patchset or a public
repository), there's likely a greater than zero chance that someone
will use it - I just can't say how much greater than zero ;).