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