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

[Jeffrey Altman]

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

On 4/11/2012 2:13 PM, Matt W. Benjamin wrote:
> Hi,
>
> Ok, that was a great overstatement.  Upstream is interested in all kind=
s of new things, but the current processes promote very careful inclusion=
 of potentially broadly applied, small changes. =20

The 1.6.0 release is a perfect example of why OpenAFS has to be careful
and how the existing processes continue to fail the needs of the
community.    The fact is that there are insufficient resources in this
community to tackle big expansive projects successfully.  The 1.6.0
release included bugs that introduced runtime data corruption of
volumes; an explosion of packets being sent to the file server from unix
clients; and a failure to retry failed RPCs in circumstances where
retries were necessary resulting in data corruption in files stored by
unix clients.  On top of that was the realization that idle dead
processing in the UNIX clients which was added back in 1.4.x was itself
contributing to file server and broader cell meltdown scenarios and data
corruption.  Regardless of what the community wanted to work on from
September to the end of March, a significant amount of resources had to
be redirected to addressing these issues to ensure that when 1.6.1 was
released on March 28th that this time we got it right.

Another fact is that the resources which were devoted to addressing
these problems overwhelmingly came from Your File System Inc. even
though the problems were well known.   Your File System had to delay
many internal projects in order to permit its developers to volunteer
addressing the 1.6.0 short comings.

You indicated earlier that you would review more things if only you were
invited to do so via Gerrit.  What do you propose should be the
mechansim?   The gatekeepers should maintain a list of all volunteer
reviewers and by a flip of a coin or in sequence assign one or more of
the volunteers to each patchset that is received?

The gatekeeping function is not funded.  The release management function
is not funded.  The testing process is not funded.  Responding to bug
reports in RT is not funded.   Where is the time supposed to come from
to manage patchset review invitations?

Where are the volunteers?   Or alternatively, where are the end user
organizations willing to fund the acquisition of resources necessary to
expand OpenAFS?

> The original question was, why isn't there more forward progress--by wh=
ich the questioner meant, not "why aren't there more commits in gerrit," =
but, "where are the new, world changing features?"  As you know, there's =
a huge backlog, and, if current rates of absorbtion continue, it will be =
2014 before more than half of them are in a release.  I'm not sure that's=
 bad, from a change management point of view, but, it seems to be a probl=
em nonetheless.
"Where are the new, world changing features?" is not the subject of this
e-mail thread.  It may be the subject of another one.  However, the
quick answer is that new, world changing features require resources to
architect, resources to standardize (if necessary), resources to
implement, resources to review, resources to test, resources to
integrate, resources to document, resources to release, and resources to
support.   Where are the resources?

You referenced code that Your File System Inc. hired you to develop.=20
That code is the property of Your File System Inc. and will be released
upstream when Your File System Inc. can do so.   Such code should be
left out of this discussion.  For OpenAFS 2.0 there is a commitment to
include:

 * pts extensions
 * rxgk
 * extended callbacks
 * RX improvements

The first has passed afs3-standardization but the code has not been
submitted to OpenAFS yet.  The second two are blocked on
afs3-standardization.  The rx improvements have been pushed upstream
already and have been actively deployed in the 1.7.x Windows series.

The final item that was originally scheduled for 2.0 was RX OSD.   RX
OSD was redesigned so that it is now an independent project from
OpenAFS.   RX OSD has its own Services IDs that multiplex with the
standard AFS services.  The RX OSD RPCs are now outside the scope of
RXAFS and therefore do not require afs3-standardization.  What we are
committed to do for RX OSD is to include in 2.0 a set of plugin
interfaces so that RX OSD can be distributed independently of the AFS
binaries.  There will be one piece that requires some form of
standardization which is a new RX packet type to permit the list of
service IDs available at a peer to be queried.

Jeffrey Altman



--------------enigD8B511D5EBB5A4A3301D07E4
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)

iQEcBAEBAgAGBQJPhdaoAAoJENxm1CNJffh40w4IAJ9zaZr2wAym8d9BAdVKEiEb
pdwXsfDvdlHSahGM8xj4NJvT2mhAvZ61ciZdpGrLld3wPgfIMoltw1V7uBVoFKj1
o8MdVwaKQnOCwkqKdFf6cFkpK7tAuKQynYAO8fzk0QglbM8tX3M3J98/c3DLLskz
QLRiAeaVnJ8lb2YDklNpMoskCB7StGAfja8YqWyAsVC5P7jYhfWSR0djPvf5L6ez
3YWcKvZEO5+sw2Y17fYVOwClOPHfIAU7whSlvK5bXV0LLUGyZ4srMYJFHQBQLLtF
8UncAVOoJLoEYrahR5lAU0kHKc2dTcCAWOuaWequJ6ioLbt3FVpq67RhbRTclBY=
=T0fe
-----END PGP SIGNATURE-----

--------------enigD8B511D5EBB5A4A3301D07E4--