[OpenAFS-devel] Moving Forwards

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9D4748BAB4C2D55A4020F48E
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

The work performed under support contracts is driven by the end user
organizations that pay for them.  Writing unit tests, regressions tests,
performance tests, and more are all desirable.  However, it is
unreasonable to expect support organizations to put the time and energy
into developing them without funding.

Support contractors do not have veto on the acceptance of code
contributions.  The gatekeepers do have a veto but rarely use it.
Things that will result in a code rejection are:

 * changes to the semantics of existing RPCs

 * submission of individual patchsets to Gerrit that cannot be
   reviewed in under an hour or which fail to build on supported
   platforms.

 * patchsets that violate the rule
   "one change per patch.  One patch per change."

 * code review objections from significant developers in the community

 * features that cannot be tested by the gatekeepers.  For example,
   functionality that depends upon hardware or operational environments
   that are not generally available.

 * protocol extensions that fall into the category of changes
   that have agreed to require afs3 protocol standardization.

 * changes to data formats without providing tools to convert
   between the old and new formats.   Upgrading to a new revision
   of OpenAFS must not prevent rolling back to a prior release.

The general rule is that if you are going to begin a large coding
project is discuss your design early and often.  Do not hold onto
code changes in your local repository.  Push changes to OpenAFS master
often and frequently rebase again current master HEAD.

With regards to IPv6.  No one is preventing you from proposing a design,
obtaining consensus and sending patchsets to Gerrit that implement the
agreed upon design.  However, I am unaware of anyone that is
volunteering to implement IPv6 support for you.  None of the end user
organizations that I speak to have indicated that lack of IPv6 support
is in fact a showstopper for them today.  Nor are any of them prepared
to fund the work.

Jeffrey Altman


On 9/9/2012 1:19 PM, Troy Benjegerdes wrote:
> Since we have no regression tests, everything can go in. And when
> a new changes completely breaks something, people providing support=20
> contracts will be motivated to write and submit better tests, instead
> of blocking or ignoring new code, which is what the current system
> encourages.
>=20
> I'd also propose that this test-driven approach be applied, as much
> as possible, to major disruptive protocol changes, such as say,=20
> wholesale replacement of all data structures that refer to an IPv4=20
> address.
>=20
> If you can produce a working testcase that will fail with a new rx
> protocol change, then you have a valid argument. Otherwise we can=20
> move ahead with some dramatic data structure changes to simplify=20
> getting working ipv6 and rxgk code available for those who don't
> have an immediate need to interoperate with any 'old' code.



--------------enig9D4748BAB4C2D55A4020F48E
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJQTWsSAAoJENxm1CNJffh4froH/i7xKTm0qgUeuo/DKUo7SVOT
nEZ5vCP/E3mZ7a2UaZU5M6pz6X+lIIIL0FWBFHBixWzq8RYs6f1IwNXj7wK4ggbE
IbTe3i6h3NUBMF8VYnvlhNY5EhjZUAXhJPrWh7CSk3P/DYQpNRgArzmDFU6kTVFW
Y+ebRfPB/EroaYluP8mdZ7fkSrOHxSZfhEaB/8QoZn7Ihc7/6jxXtXM2mJ1bUjjh
wb1qc0Mu59zV6YZM2IwGUV9M5UEbvxuohu+1d5yLrXBl8/UgFegrDpCOfyPZdgU4
9PgmNnCw89kxn/ntMQsbieBXHRmQ8TFwT7Y95i1CbCeQoD+CVf+/13OUx5t5HYI=
=f2Lf
-----END PGP SIGNATURE-----

--------------enig9D4748BAB4C2D55A4020F48E--