Re-reading my words, I should have chose them more carefully. Not to be too philosophical here, but when I think of "truth", I think of something that is unchanging/timeless. I wish I would have said the following paragraph instead:
"Portions of the spec are evolving at different paces and have different > levels of maturity. It would be nice to make it clear which portions of the > spec are "standard" and which are "evolving". We could use AEPs as a way of > making this clearer although we could make it clear without them too." I agree with Scott that having an AEP process be a barrier to getting things done would be a very bad thing. We don't want to create any barriers to participation. I also agree that for open-source, and Apache specifically, is a do-ocracy. I think part of the issue here is that it's hard to *do* things with C than other languages so there is a bit of a disadvantage playing in a do-ocracy. People don't typically reach for C when they need to prototype something. :) I would like to see us be a little more of a think-do-acrocy when it comes to important, high-level components of Avro (e.g. light-weight RPC). It would be nice to have some simple consensus before code starts getting slung around; otherwise, we'll see things in our spec like "The double is converted into a 64-bit integer using a method equivalent to Java's doubleToLongBits and then encoded in little-endian format." Not to say we would ever do such a thing. :) -Matt On Thu, Jun 3, 2010 at 5:15 PM, Doug Cutting <[email protected]> wrote: > On 06/03/2010 04:37 PM, Matt Massie wrote: > >> I think it's misleading to see the spec as a single source of truth. >> There >> are portions of the spec which are much more set in stone (e.g. the binary >> serialization format) than others (e.g. lightweight RPC) are more a work >> in >> progress. It would be good to make that clearer to future implementors >> and >> users. I think AEPs should have a status assigned to them similar to RFCs >> http://en.wikipedia.org/wiki/Request_for_Comments#Status. >> > > The spec is already versioned. We could add a status to each section of > the spec if we like. But I don't see how status is an argument against a > having a specification document. > > The last incompatible change made to the spec were the file format changes > in February, prior to any known adoption of the file format. Prior to that, > RPC was last changed incompatibly in October, also prior to any known > adoption of RPC. I don't think we should add things to the spec until we > are fairly confident they are stable. And once something is in use, we > should work hard to never change it incompatibly. > > Doug >
