[On afs3-standardisation, Andrew wrote: ] >> However, that does not preclude a specification, which raises another >> question: can/should we publish OpenAFS-specific standards? If we make >> I-Ds that clearly demarcate themselves as for OpenAFS and not AFS-3 in >> general, it would seem valuable as a standard specification for these >> kinds of things. The same thing could go for the Ubik voting/beacon >> protocols, cmdebug, and other things that so far have appeared to be >> considered "internal" to OpenAFS, but still travel over the wire.
[and Tom replied ... ] > As one of the people Andrew spoke with about this earlier today, I'd > like to second this proposal. Even if we merely use the I-D > format--yet publish via our own OpenAFS-specific document submission > stream--I think there would be a lot of value in formalizing the > process of changing/documenting OpenAFS-specific behavior. This is the wrong place to be having this discussion - it really belongs on the OpenAFS lists. I've CC'd openafs-devel with this response, hopefully we can continue this discussion there. I have a number of concerns with this approach. Firstly, it's important to note that I-Ds are not an archival document series. Publishing an I-D may serve as a useful, if heavyweight, means of encouraging discussion, but it does nothing in terms of ensuring that the document is available in the future. The only way to do so is to advance the I-D to an RFC. However, discussing OpenAFS implementation details within the RFC series is definitely inappropriate. Secondly, we already have a mechanism for discussing code changes to OpenAFS, and I can't see why structure changes can't use that same mechanism. If it's an OpenAFS implementation detail, then surely it should be decided in exactly the same way as every other OpenAFS implementation detail. If a better form of documentation is required, then I would much rather that that documentation lived within the source tree, than in some location on the web that's subject to a far worse degree of bit rot. We've already discussed, at length, on how we should be using openafs-devel for design review in advance of coding, and this seems like just another instance of that. Cheers, Simon. _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
