On 11 Apr 2012, at 18:54, Matt W. Benjamin wrote: > > Yes. Every developer who worked on byte-range locking code, for example, > which > is mainly but not strictly me, strongly preferred it. We wanted to use a > mainstream, > open-source unit testing suite, and CUnit is that suite.
Fine. In which case the way to handle this would be to have a discussion, on openafs-devel, about either adding a second unit test framework, or moving over from TAP to CUnit. Making a single trivial patchset dependent on a significant change in developer tools is not a good way to get that patchset into the upstream tree. > I don't recall what the overlap is with CDDL. There is a CDDL AVL > implementation in > a number of components I've worked on, and I got approval from Derrick to use > it. > Replacing it at some point would be manageable, at some point, but in fact, > this sort of > blocker is a great example of how OpenAFS creates unnecessary obstacles to new > code, under the guise of simplifying maintenance. If OpenAFS isn't legal to distribute it's pretty much worthless. There's a significant moral obligation on all of us who develop for OpenAFS, and a legal obligation upon those who actually distribute it, to ensure that all of OpenAFS's various copyright licenses are compatible with each other, and acceptable to the distributions which bundle OpenAFS. This is already a non-trivial problem, and that problem grows exponentially with each new license that gets added, as all of the licenses terms have to be compared with the terms of all of the other licenses of all of the objects that get built into the binaries we distribute. I really don't see how ensuring licensing compliance can be seen as an "unnecessary obstacle" by anyone who cares about the future success of the project. > Yes, given an upstream uninterested in new work, developers will perceive it > as not > worth their time to keep such a process moving. I think that the huge volume of changes that have gone through gerrit, from a large body of developers, demonstrates the fallacy of this statement. Cheers, Simon _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
