On 3/4/2012 3:08 AM, Garrett Wollman wrote:
<<On Sun, 04 Mar 2012 02:43:01 -0500, Jeffrey Altman <[email protected]> said:The other list you can subscribe to is [email protected] which sends notifications for each patchset that has been approved via Gerrit upon its submission to the openafs git repository.Which has nothing to do with the planning for the release process, which seems to be undertaken by some unknown group of people without any communication to the wider community.[1] By contrast, most other open-source projects have a public release schedule or set of release milestones, and these things are announced on an obvious mailing-list (like one whose name suggests that it is targeted towards developers) on a regular basis. -GAWollman [1] I hope it is not the case that these people together represent most of what's left of the AFS community outside of IBM labs. For starters, there is no longer an IBM AFS Product group. All that remains of AFS development is OpenAFS. While it is true that the openafs-cvs list has nothing to do with the release process, gerrit.openafs.org does, and I pointed you at that first. All patchsets which are being considered for inclusion in a release are processed through gerrit.openafs.org. Not only when they are initially reviewed and processed for the master branch but when they are being pulled (or cherry picked) to a release branch as well. Requests for pull ups are performed by submitting a cherry picked patchset to the desired branch. Objections to pull ups being applied are voiced by voting -1 on the patch set. 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. Identifying the root cause of a problem is critical because if we don't, we cannot be sure that the problem has in fact been addressed. To identify root cause we work with members of the community that are experiencing an issue and have reported it to [email protected] (or who have a private support contract.) Identifying root cause in really hard cases such as an apparently random data corruption issue can take a while. Both the investigator and the tester need to have available cycles and the problem must be reproducible. 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. 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. There is a broader problem as well which is that there is a significant concentration of development resources in a very small number of organizations. Your File System Inc. is responsible for funding or implementing over 60% of the code contributions to OpenAFS. Sine Nomine is responsible for about 20% and the remaining 15% or so come from approximately 30 to 35 other developers or documentation writers over the course of a year. Over the last three years Your File System and Secure Endpoints have averaged $225,000 a year in unfunded work on OpenAFS. This covers gatekeeping, release management, testing, and following up and addressing every issue that is reported to [email protected] for which there is not already a known fix. It is my opinion as a gatekeeper that there can be no long term improvement in the OpenAFS release scheduling until such time as the underlying financing problems are addressed. Until OpenAFS has some resources to manage, the gatekeepers will continue to do the best we can with the time that is available to us. Jeffrey Altman |
signature.asc
Description: OpenPGP digital signature
