Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Plain View
Avro, mail # dev - Avro governance and Avro Enhancement Proposals


+
Bruce Mitchener 2010-06-03, 08:46
+
Philip Zeyliger 2010-06-03, 22:07
Copy link to this message
-
Re: Avro governance and Avro Enhancement Proposals
Jeff Hammerbacher 2010-06-03, 23:16
My opinion roughly coincides with Philip. I don't think Avro is large enough
to require AEPs just yet. I think a single spec is great, and clarification
of levels inside that spec would be greater.

On Thu, Jun 3, 2010 at 3:07 PM, Philip Zeyliger <[EMAIL PROTECTED]> wrote:

> I'm -0: I actually really like the fact that there is one spec, and that
> it's the source of truth.  Since Python is being brought up as an example,
> I'll mention that my experience is that it's incredibly annoying to run
> into
> some documentation, and it points you to some proposal, and then you have
> to
> decipher what was proposed from what was implemented.
>
> I think we're still small and lightweight enough that JIRA and the mailing
> list are sufficient for circulating most proposals.
>
> -- Philip
>
> On Thu, Jun 3, 2010 at 1:46 AM, Bruce Mitchener
> <[EMAIL PROTECTED]>wrote:
>
> > Hello all,
> >
> > I had some discussions with cutting recently about moving to an AEP (Avro
> > Enhancement Proposal) process for Avro, similar to the PEP process for
> > Python (http://www.python.org/dev/peps/).  PEP-0001 (
> > http://www.python.org/dev/peps/pep-0001/) should give a pretty good (but
> > longer) description of this process.
> >
> > In short, major and important changes would be put forward as an AEP.  An
> > AEP would have an editor who owned the document, worked to build
> consensus
> > and shepherds the document to approval.  Approval of an AEP would be done
> > via a vote of the PMC.
> >
> > AEPs could be changes to the implemenations or the processes surrounding
> > Avro development (like how we format source code, how we handle code
> > reviews, how we perform releases, etc).
> >
> > AEPs could be managed in the wiki or in Subversion and published to the
> > website.  I'm interested in hearing what people think in this area.  I'm
> > somewhat partial to managing them in Subversion as that:
> >
> >  * Puts the history in one spot.
> >  * Allows us to update AEPs with the same patch as implementing a new
> > feature in the code.
> >  * Keeps things under the appropriate licensing and approval processes
> that
> > we have now, especially since anyone can edit the wiki.
> >
> > As part of this, I think that it makes sense to break some things out of
> > the
> > specification and out of their current locations on the website:
> >
> >  * GenAvro IDL should become a new AEP.
> >  * An AEP should be written to describe container files and that can be
> > removed from the spec.
> >  * RPC mechanisms should be AEPs rather than part of the core spec.
> >
> > As part of this, if each AEP lists which implementations support the
> given
> > AEP, it would also help solve the issue being discussed in
> > https://issues.apache.org/jira/browse/AVRO-358 (specifying levels of the
> > Avro implementations).
> >
> > Thoughts?
> >
> >  - Bruce
> >
>
+
Matt Massie 2010-06-03, 23:37
+
Doug Cutting 2010-06-04, 00:15
+
Matt Massie 2010-06-05, 01:29
+
Doug Cutting 2010-06-07, 16:43
+
Matt Massie 2010-06-07, 19:51
+
Bruce Mitchener 2010-06-08, 02:16
+
Bruce Mitchener 2010-06-11, 05:20
+
Jeff Hammerbacher 2010-06-11, 06:18
+
Scott Carey 2010-06-04, 00:00