[OpenAFS-devel] Gerrit reviews and the rate of acceptance

[Simon Wilkinson]

On 11 Apr 2012, at 18:54, Matt W. Benjamin wrote:
>=20
> 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=20
> 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