avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Massie <m...@cloudera.com>
Subject Re: Avro governance and Avro Enhancement Proposals
Date Sat, 05 Jun 2010 01:29:01 GMT
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

"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.  :)


On Thu, Jun 3, 2010 at 5:15 PM, Doug Cutting <cutting@apache.org> 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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message