>> In the presence of a version control system, even one as basic as CVS,
>> deletion isn't fundamentally worse than leaving them to bit-rot out of
>> [sight] - they can always be recovered from the version-control system
>
> Not for people who only get the release tarballs.
Good point - didn't think of that.
>> and has the virtue of not cluttering up the source tree with things that
>> aren't adequately supported.
>
> They are supported, Paul just wants to find ways to lower the burden.
In that case, they're not bit-rotting, so should no more be moved out of
sight than deleted. But if we get to the point where we have no-one to
maintain them or no-one who can test them (a prerequisite of full
support) before releases, I can see the sense of moving them into a
subdirectory - whose ReadMe.txt can say "we haven't tested these but we
try to keep them up to date and one of them might work for your
platform, or at least be a good start-point; if you need to fix it up,
please send us a patch."
Eddy.
_______________________________________________
Bug-make mailing list
Bug-make@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-make
