cunit integration, cddl: was Re: [OpenAFS-devel] Gerrit reviews and the rate of acceptance

[Matt W. Benjamin]

Hi,

----- "Simon Wilkinson" <simonxwilkinson@gmail.com> wrote:

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

To the best of my recollection, Russ' position was, this isn't a blocker
for him, but at some point there would be a tap integration with CUnit.
I'm happy to work on that.

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

Unfortunately, licensing is just a sticky area, and the issues need to be taken
case by case.  I have no personal stake in the matter, really, but as usual I
would take the position that if our project is wise, we will look very carefully
before we take the CDDL-unfriendly position, if only because we made use of unicode
normalization code in the dir2 module, as well.  (That was by agreement in Pittsburgh.
Of course, the project has no commitment to ship in this form.)
While everything can be replaced, replacement has cost in time and dollars, and I think the
project would be wise to take the most pragmatic approach available, after due
consideration.

Regards,

Matt

-- 
Matt Benjamin
The Linux Box
206 South Fifth Ave. Suite 150
Ann Arbor, MI  48104

http://linuxbox.com

tel. 734-761-4689
fax. 734-769-8938
cel. 734-216-5309