On Mon, Mar 02, 2009 at 02:22:05PM -0700, John Hein wrote:
> 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?

One reason would be to have a clearly documented way of doing this. Most
people would assume that they need matched client server, at least at the
major rlease level (2.5 bs 2.6). What I am thinking is that a clearly
labled sub project, called somehting like "client side for older amchines",
starting at a different version number, and moving foward on it's on
sequence would be easier to understand. Does that make sesne?

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

I think that most of the new features are conecntrated on teh server end,
if I am not mistaken. The last client side enhancement that rose to a
visibilty level for me was client side config files, so that you don't ahve
to ahe many, many deifernt dumptyes, where the only overide was, say where
teh exclude file went. or am I missing something here?
> 
> 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).

I am not trying to start my own fork. What I am hopping to do is to get
others interested in this. It makes no sense to create a fork for somehting
that only I see value in.
> 
> 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 ;).

-- 
One of the main causes of the fall of the roman empire was that, lacking
zero, they had no way to indicate successful termination of their C
programs.