On 4/11/2012 2:13 PM, Matt W. Benjamin wrote: > Hi, > > Ok, that was a great overstatement. Upstream is interested in all kinds of > new things, but the current processes promote very careful inclusion of > potentially broadly applied, small changes.
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 which > 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 problem 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. 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
signature.asc
Description: OpenPGP digital signature
