[OpenAFS-devel] 1.6.1pre3?

[chas williams - CONTRACTOR]

On Sun, 04 Mar 2012 08:43:16 -0500
Jeffrey Altman <jaltman@your-file-system.com> wrote:

> OpenAFS, unlike many other open source projects, say Linux, Apache, Samba=
, Mozilla, etc., does not have any central resources.=C2=A0 The OpenAFS com=
munity does not fund development.=C2=A0 Nor does it fund the cost of gateke=
eping, release management, or testing.=C2=A0 The gatekeepers have said repe=
atedly over the years that we want to move to a more regular release cycle.=
=C2=A0 Unfortunately, wrenches are constantly being thrown in the path of p=
rogress.=C2=A0 It took nearly five years to get 1.6.0 out the door because =
of known instability issues.=C2=A0 Having shipped 1.6.0 in August, 1.6.1 ha=
s yet to ship because of production problems with that release (NAT pings, =
idle dead, and related issues.)=C2=A0 The release schedule is to release 1.=
6.1 as soon as the root cause of the known issues have been addressed.=C2=A0

which is possibly the result of the rather long release cycle. without
previous releases of these features there were far fewer testers before
the 1.6.0 release.

part of this is also lack of any sort of server testing framework.  how
does it perform under load?  currently the only way i know to test this
is to install openafs in a university/large company setting.

> In terms of long term planning for releases such as the milestones listed=
 on www.openafs.org/roadmap.html, OpenAFS is at the mercy of outside forces=
.=C2=A0 For starters, the development organizations that intend to contribu=
te a feature have to in fact do so.=C2=A0 Secondly, after the 2008 NJIT bes=
t practice workshop the community decided that the standardization of the A=
FS protocol should not be left in the hands of OpenAFS.=C2=A0 The afs3-stan=
dardization process was formed and the OpenAFS Elders agreed that no protoc=
ol changes would be accepted into OpenAFS without the afs3-standardization =
process being satisfied.

somewhat.  if you dont actually present anything for standardization
then the outside forces are not contraining your progress.

> Simon argues that we should have timed releases no matter what.=C2=A0 The=
 big problem with time releases occurs when there are significant issues th=
at are extremely time consuming to address, many of the resources that are =
available for release management get spent on debugging and testing.

it may be impractical to do this for all the platforms that afs
supports.  but with virtual machines it should be possible to automate
most of the work for some "preferred" platforms and provide a set of
install binaries that people can try.  if building afs from source is a
hurdle, you need to make that hurdle smaller.