I largely agree that we are small and lightweight enough to avoid these things for much of what we do. However, having a heavier-weight process standardized as a 'go-to' for the rare times when those tools aren't good enough is a good idea.
Apache is a "do-ocracy", IMO process like this should not get in the way of contribution, it should facilitate getting big, complicated, or contentious changes right. I worry that potential contributors will be put off if they get the impression that they can't contribute without an AEP -- whether true or not. There are times when a process like this is useful. Once a feature clearly will take a long time to get consensus in JIRA, a PMC member might optionally 'promote' it to an AEP. An AEP or something like it for Avro 2.0 proposed major changes will likely be necessary. +1 for defining an AEP for big or contentious changes. A default 'heavier weight' process as a go-to for some situations will be beneficial IMO. -0 for using this process as the default way to initiate a proposal. It should be very clear to potential contributors that this is not necessary, but may become so if the issue is contentious or complicated. I think starting in JIRA or the mailing list, and escalating if necessary (should be rare) is a good default. What we do now is working for 95% of what is going on. -1 for placing authoritative final documentation in the AEP. A final spec for a feature once it is going to be released needs to be stand-alone so that users don't have to wade through proposals to figure out how things are supposed to work. It might be referenced from the AEP or maintained along side it, but needs to be seen as a resource for the feature's users moreso than the resource for those that built the feature -- and if the AEP itself is treated as documentation, the result will tend to be more of the latter. Essentially, part 4 of an AEP (pronounced 'ape'?) -- specification -- should exist elsewhere and not only in the AEP. I can be convinced otherwise but I definitely have concerns about dual-pursposing it for end user documentation and developer process. -Scott On Jun 3, 2010, at 3:07 PM, Philip Zeyliger 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 > <bruce.mitche...@gmail.com>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 >>
