On Mon, Mar 02, 2009 at 04:46:43PM -0500, Dustin J. Mitchell wrote:
> 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
> :)

Well, the overiding reason is the issue of clarity that I mentioned
befoere. Otherwise, it certainly becomes a FAQ, and most likely simply
results in many potential suers deciding not to use the project, once they
evaluate the dependacy requirmants for the newer versions.

As for that version still exisitng. i certainly hpe that all versions still
exist in teh soruce code conytrol ssytem! if not, maybe I need to look
arounf for old tarballs :-)

> 
> > 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 am most certainly not trying to do a hostile  fork here!
> 
> 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.)

That actually sounds reasoanble.
> 
> 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.

That would be wonderful. I am willing to put some effort into this, and I
have some old ssytems to do testing, and porting work one.
> 
> 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!


Right on!
-- 
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.