Hi, Some comments below.
On Mon, Jan 30, 2012 at 12:00 PM, Keith Turner <[email protected]> wrote: > On Mon, Jan 30, 2012 at 2:34 PM, Lewis John Mcgibbney > <[email protected]> wrote: > > Hi Keith, > > > > On Mon, Jan 30, 2012 at 7:14 PM, Keith Turner <[email protected]> wrote: > > > >> > >> Do you guys have any coding standards? Accumulo settled on some > >> standards for indentation, etc. Its on our source web page [1]. I > >> did not see anything like that on the Gora web site. > >> > > > > Ripping this from your previous thread, I will start by saying that no, I > > don't think we do have any standard coding practice as of yet. This is > > something which we could possibly migrate to Gora from Accumulo... Wdyt? > > This should be added to the wiki page I think. > > > > When we started as an apache Project, someone suggested that we adopt > a coding style from the beginning. So we did. We took the Lucene > style and modified it slightly. I think Hadoop also uses the Lucene > style, but I am not positive about this. > > The modifications to the Lucene style that I can think of are as follows : > * Increased line wrap to 160 columns (we did not like wrapping at 80) > * Use a new line with single statement if/else blocks instead of > single line (we did not like how this looked) > > Could diff the Eclipse formatting XML to get a complete list. > > For Gora, if a coding style was adopted would need to decide how to > implement it and what style to adopt. Do you just apply to new code > going forward or pick a date and reformat all of the code? We just > picked a date and reformatted all of the code using Eclipse soon after > importing into Apache svn. > Most of the styling in Gora comes from the Hadoop/lucece world, but there is no strict enforcement to do this. It is also very similar to the sun spec except 2-spaces for tabs. Other than that, we can just copy one of the wiki pages + checkstyle conf from either of the related projects, and modify that to suit our needs. For the existing code, I think we can just create an issue, and apply the patch there. > > > > >> > >> Also, do you code review committers changes or use lazy consensus? > >> > > > > Right now we've been using a combination of both, for example some of us > > are using Gora with HBase and others with Cassandra, this means that it > > might be a bit difficult to test HBase stuff if you're a Cassandra user > and > > vice versa. I think we've found a happy medium between mostly lazy > > consensus followed by mainly dev@ discussion should there be any > problems... > > That sounds very reasonable. So I can make changes to Accumulo store > as needed but look for consensus before making other changes. > > Historically, we do pre-commit reviews, and lazy consensus. It is also ok to commit trivial stuff without a jira or review. However, for anything that is non-trivial, it is best to open a jira, attach the patch, and ask for a review. If no interest comes up after some time, we can assume lazy consensus. > > > > Thanks > > > > Lewis >
