I will open an issue and work on this proposed javadoc. I am a "first principles" type of person, and I do not see myself being able to effectively do stuff until I understand the Drill API inside-out myself. A result of the learning process should be contributed back to the project.
I'll start with a javadoc and target 1.3. Sounds good? On Thursday, September 10, 2015, Daniel Barclay <[email protected]> wrote: > Ted Dunning wrote: > >> ... >> I think that we should have a rule that every class should have javadoc on >> the class. >> > > Since it will take a long time to get to that state, we should > probably start with whichever are the most important classes to > document. > > That fuzzy set of "most important" classes probably includes: > > - classes relevant to using Drill's application-programming > interfaces (e.g., Drill's driver JDBC now (which already has > significant documentation), and, in the future, DrillClient/etc.) > > - classes relevant to developing plug-ins > > - most classes at the roots of big and/or significant hierarchies > (since they specify methods, contracts, and protocols used by many > other things) > > - other classes that methods, contracts, and protocols used by many > other parts of Drill > > Daniel > > > P.S. Speaking of documentation... > > Could a committer approve and merge my DRILL-3641 IterOutcome doc. > pull request at https://github.com/apache/drill/pull/113? (Only > one file to review! only an enum class's documentation!) (It > should help avoid future bugs like DRILL-2288 and DRILL-3569.) > > Also, could anyone take a look at > https://github.com/apache/drill/pull/118? It's mostly just Javadoc > edits on code somewhat related to storage plug-ins (things I > encountered in starting to explore how to write a storage plug-in). > > Thanks, > Daniel > > > -- > Daniel Barclay > MapR Technologies >
