On Sun, 04 Mar 2012 08:43:16 -0500 Jeffrey Altman <[email protected]> wrote:
> OpenAFS, unlike many other open source projects, say Linux, Apache, Samba, > Mozilla, etc., does not have any central resources. The OpenAFS community > does not fund development. Nor does it fund the cost of gatekeeping, release > management, or testing. The gatekeepers have said repeatedly over the years > that we want to move to a more regular release cycle. Unfortunately, > wrenches are constantly being thrown in the path of progress. It took nearly > five years to get 1.6.0 out the door because of known instability issues. > Having shipped 1.6.0 in August, 1.6.1 has yet to ship because of production > problems with that release (NAT pings, idle dead, and related issues.) The > release schedule is to release 1.6.1 as soon as the root cause of the known > issues have been addressed. 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. For > starters, the development organizations that intend to contribute a feature > have to in fact do so. Secondly, after the 2008 NJIT best practice workshop > the community decided that the standardization of the AFS protocol should not > be left in the hands of OpenAFS. The afs3-standardization process was formed > and the OpenAFS Elders agreed that no protocol 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. The big > problem with time releases occurs when there are significant issues that 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. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
