On Tue, 28 Aug 2012 17:28:46 -0700 Russ Allbery <[email protected]> wrote:
> There is considerably more that needs to happen with AFS than there > are currently time and resources available to do it. Standardization > is one of those things. There are many. The primary reason why any > specific thing does not get done in AFS, whether that be major new > functionality work or protocol specification work, is "not enough > time/resources." I don't see how this could possibly be true, regardless of the little details of actual AFS development. "Not enough time" is a reason why we don't get _everything_ done, but as to why any one particular "task X" doesn't get done, the reason is that it is prioritized lower than everything else. The only way that "Not enough time" would be the reason for task X not getting completed is if task X could not be done even if myself, Derrick, Simon, et al were working on nothing but task X full time. There are no tasks where that is true, that I am aware of. I think why I don't like your phrasing of this is that to me, it sounds like saying "the _only_ way standards work will proceed is if there are 25 hours in a day, or more people are brought on to the process" (that is, the only way is if more time/resources are obtained). Whereas my opinion is that it is more true to say "standards work will proceed if we work on it instead of working on other things A, B, and C" (that is, if we reprioritize tasks). > Now, with that as a given, the scarce resources can, of course, be > allocated in various different ways. More of them could be allocated > to protocol work than functionality work, for example. But that's not > actually as clear-cut as it sounds. Some types of work can't just > happen eventually, when someone gets around to it. There is quite a > lot of development work that needs to either happen within a > particular time frame or will not happen at all, because the resources > simply won't be spent on that problem unless the result can be > achieved within a particular time period. So, from this, what I hear is that the reason standards don't get done is that standards aren't as important as OpenAFS implementation tasks A, B, and C. Whether or not that is "true" is the opinion of individual developers, and is never well-defined or communicated or anything like that. I also think that is becoming less and less true, since the lack of ipv6 support, lack of strong crypto, and lack of reasonable wire speed, and other features, are becoming blocking issues for an increasing number of users. I do not spend 100% of my time on AFS on things that absolutely must be done within a certain timeframe, nor do I spend 100% of my time on things SNA gets paid to do. At the very least, the remainder of that certainly could go into standards work, and right now almost none of it does. I cannot be the only person for which that is true. > Anyway, the point that I'm trying to get at here is that the licensing > question isn't going to be the thing that prevents AFS from having > standards documents. Nothing about the license situation prevents > people from stepping up to do the work. The path forward is > relatively simple, just difficult: decide that standardization is > important, write standards documents, read and review standards > documents, revise standards documents, and then publish them somewhere > if they've reached consensus. The last could be any web site anywhere > or even just something on Github. In terms of what license released materials will be in, sure, that doesn't seem likely to prevent anyone from working on this. However, any uncertainty about licensing, document storage/archival locations, or the general future of the body, etc etc, certainly can and will kill motivation. -- Andrew Deason [email protected] _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
