Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Threaded View
Avro >> mail # dev >> Avro governance and Avro Enhancement Proposals


Copy link to this message
-
Re: Avro governance and Avro Enhancement Proposals
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
>
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB