On Mon, Sep 10, 2012 at 12:17 AM, Troy Benjegerdes <[email protected]> wrote: > On Sun, Sep 09, 2012 at 10:29:20PM -0400, Jeffrey Altman wrote: >> On 9/9/2012 9:15 AM, Simon Wilkinson wrote: >> > Hi all, >> > >> > Following on from last weeks plethora of resignations and negativity, I >> > want to propose some ways that we can move forwards, and hopefully reduce >> > the inertia that has built up in our development process. One of my key >> > aims here is to reduce the workload on the remaining Gatekeepers, and to >> > remove any potential for them becoming road blocks in the process. I >> > should add that I'm proposing all of this in an individual capacity - my >> > employer has had no input into what follows! >> >> While I appreciate your desire to remove the gatekeepers from being >> roadblocks, in some respect that is exactly what the gatekeepers are >> supposed to be. The gatekeepers have a responsibility to ensure that >> the distribution that is "OpenAFS" maintains interoperability with IBM >> AFS and does not introduce code changes that destabilize existing >> deployments or result in data loss > > Two examples where it does appear the current gatekeepers are roadblocks > because some or all of the gatekeepers have a vested financial incentive > to ensure all development goes through their respective organizations: > > 1) specification of a wire protocol and incremental implementation, so > we can see that IPv6 support is progressing. >
Troy, Your frustration at the slow rate of progress is understandable, but your attacks are leveled at the wrong people. IPv6 support is something that is going to take literally years of effort; many of the blocking issues fall entirely outside of the Gatekeepers' purview. We have had more protocol standardization discussions relevant to v6 than I care to count. RPC Refresh will happen. However, we have very limited resources--resources, for better or worse, whose time mostly went elsewhere while the issue of .xg file IP rights was still undecided. In terms of standardization, ratifying the rxgk standards is far more essential to the mid-term viability of the product. While I cannot speak for the developers as a whole, there does appear to be consensus (and it is certainly consistent with that I hear) that IPv6 is quite far down the wish list. This is not to say that it won't happen; merely that we all have had better things to do. Once we can achieve consensus on the rxgk drafts, there is a chance that RPC Refresh will come to the front of the docket, although this is entirely dependent upon availability of critical resources to finish the refresh draft (and satisfaction of all legal concerns with regard to the large amount of IPL code that will be in the document). Most of what goes on in this community happens because someone has an "itch" they wish to scratch, and subsequently do so by either: a) contributing their own time, or b) paying someone else to dedicate their time to the matter. If v6 really interests you, then I sincerely doubt anyone around here is going to object to your help. > 2) rxgk (and the rxk5 implementation, which, to my understanding *worked* > but was dropped) > > Is there any public documentation of past code changes that resulted in > data loss and/or destabilization so I can write test suites? > You could always cull the openafs RT queue. Granted, many of the serious crashing issues go through the support organizations' queues (due to confidentiality requirements), and, thus, much of the information you would want is, alas, proprietary (granted, the general information regarding why something crashed need not be proprietary, yet the cost of scrubbing and anonymizing incident data tends be very high--and involve dear resources). > So if I get a working rxk5 on the latest codebase, does anyone have any > ideas for a name/trademark better than 'TFS' (troy's file system) so that > there is no confusion between that fork and OpenAFS? If there are going > to be stupid legal arguments that IBM owns the .xg files and I can't > actually distribute a modification that moves forward from OpenAFS, > then I'd also like to know now so I can start looking at other more > open protocols to migrate my files to. > > If the gatekeepers wish to remain relevant, than I would please request > they come up with a workable IPv6 wire protocol that can be incrementally > developed and deployed to get working isolated cells running v6 within > 6 months. Disregarding the unreasonable time-frame, I think you misunderstand the role of our gatekeepers. We already, at least ostensibly, have a fair-sized community of people who work on protocol design. As I mentioned above, we've discussed a plan many times, yet none of us have found the issue compelling enough to drive the requisite stream of documents through to completion. If you expect to have v6 working in short order, you're going to end up being very disappointed; just one component of this effort will take in excess of six calendar months. Regards, -Tom _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
