On Mon, Mar 2, 2009 at 4:22 PM, John Hein <jhein AT timing DOT com> wrote:
> 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.

Yes, we'd be happy to do so, right now.  The branch still exists.  As
you indicate, cutting a new release would require further discussion
:)

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

This is my preference, though -- a fork does not necessarily have to
be hostile!  The advantage here is that someone other than the current
developers is responsible for marshalling patches and making releases.
 I speak only for myself, but I'm happy to hack on and commit fixes to
such a fork.  I just don't want the burden of maintainership.

I think that the first step after the fork should be to rip out the
server stuff, so that the forked project *only* builds a client.  I'd
also like for it to have a different package name, but to keep the
version numbers compatible with Amanda (so if the fork is of
Amanda-x.y.z, the first release would be AmandaMinimalClient-x.y.z,
and the next AmandaMinimalClient x.y.z.1, etc.)

If a few interested folks sign on as co-maintainers, then I think this
can be a sustainable project that does not sap too much of anyone's
time.

Dustin

P.S. This would have an advantage for mainline development, too: with
a maintained minimal client available, we can recommend that those who
cannot install the newest Amanda use the minimal client, and we can
focus our compatibility testing on that minimal client.  Everyone
wins!

-- 
Storage Software Engineer
http://www.zmanda.com