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