Thanks for all your valuable inputs. 1. For new files lets use a standard and lets use the other thread to discuss what that standard should be. Venkat chimed in and mentioned about something in sqoop1, so my next goal is to get this wiki from DRAFT to CLOSED. https://cwiki.apache.org/confluence/display/SQOOP/Sqoop+2+Coding+Guidelines 2. For existing files that have been committed to Sqoop2, lets not modify it and refrain from even changing import order etc and some changes are left to the discretion of the reviewer
Closing this discussion thread for now. Note: Qian -> thanks for your inputs on #3, As much as I's like to spend cleaning up every file, its not the best use of our time at this point, since there is a lot of code in Sqoop2 that uses non-standard coding style, not just on import order, but various other things. Best, *./Vee* On Wed, Dec 3, 2014 at 7:07 PM, Xu, Qian A <[email protected]> wrote: > IDE will organize imports automatically. For new files, it's okay. For > existing files, it will make extra diff lines for reviewers. As a reviewer, > I'd not see such unrelated changes as many as possible. And as a code > submitter, I accept the fact and I'd rather take five minutes of my time to > avoid this. > > I also think Veena's 3rd idea is great in long term. It'd be great to > create a jira to add static style check step in Maven, so that import > ordering will always be checked. And we can fix imports ordering issue in > one commit. From then on, unordered imports cannot be committed > theoretically. > > --Stanley (Qian) Xu > > > -----Original Message----- > From: Zhou, Richard [mailto:[email protected]] > Sent: Tuesday, December 02, 2014 2:53 PM > To: [email protected] > Subject: RE: code-style in sqoop. > > I agree with Jarek's point. The import order is not our main interesting > for the time being, since we are still busy with functionality development. > However we still need to keep the code-style in mind when committing code. > I prefer 1#. > > -----Original Message----- > From: Veena Basavaraj [mailto:[email protected]] > Sent: Tuesday, December 02, 2014 10:49 AM > To: [email protected] > Subject: Re: code-style in sqoop. > > As a apache newbie, I realize the the use of the word "VOTE" might have > raised a few eyebrows!. Pardon my use of word vote. > > Here is what my sincere goal was. > > I wanted to get a pulse check on how the rest of the developers > contributing to Sqoop feel about having a code /style standard and how we > should start using them in sqoop since it is something most good projects > follow. > > So let me rephrase my sentence, so disregard the work VOTE:) > > What should be the most suitable path we should take to enforce the coding > guidelines and esp the import ordering going forward? > > Here are the 4 options I suggested, if there is something else anyone > wants to add feel free to. > > > 1. We do not care about the order, so lets not bother if reorder > occurs, there are projects that follow this ( kafka) > 2. We do care, lets impose the rule going forward on any file we touch, > lets all get the formatter in place in IDE. > 3. We do care a lot, lets fix every file in the next few weeks. > 4. We do care, but lets not modify any existing file, but only impose > this on new files.( this means every developer diligently uses a formatter > and does not add code that does not follow the sqoop style guide, it is > based on mutual trust that this will happen) > > > > Kindly choose an option that you feel is apt and lets discuss what seems > like a best option for this project at this point. > > Resolving this quickly would be good since we can all be on the same page > when it comes to code patches and reviews. > > > > > Best, > *./Vee* > > On Mon, Dec 1, 2014 at 6:22 PM, Jarek Jarcec Cecho <[email protected]> > wrote: > > > I believe that we currently do not particularly care about the import > > order - e.g. it can be arbitrary. However at the same time we do care > > about keeping patches focused on given functionality and we’re > > discouraging unnecessary changes such as reordering the import > > statements. This means that one can put new import statement pretty > > much anywhere as long as the existing import statements won’t be moved. > > > > I’ve opened question of applying the new code policies to existing > > files in the original email thread, so let’s perhaps continue the > > discussion there to have one thread with entire discussion? > > > > Jarcec > > > > > On Dec 1, 2014, at 11:30 AM, Veena Basavaraj > > > <[email protected]> > > wrote: > > > > > > One of the reasons we wrote the coding guidelines wiki ( and we > > > should continue to add more of the sqoop nuances ..) is to be > > > productive and > > have > > > agreed upon rules on coding style/ standards. > > > > > > First, Richard, Gwen for your reviews.! I am assuming the LIKE as a > > > positive indicator. > > > > > > I would be glad if the rest of the members can spend a few minutes > > > on > > this > > > wiki and leave a comment on things that they want to further > > > discuss, > > else > > > we will close this by tomorrow evening and create a formatter for > > > eclipse and intelliJ that follows these rules. > > > > > > > > > Second, there is one topic that comes up again and again in the Rbs/ > > > reviews and is a constant source of time sink IMO. > > > > > > So lets take a vote on how we should enforce the import order in the > > files. > > > > > > Here are the 4 options I suggest, if there is something else anyone > > > wants to add feel free to. > > > > > > > > > 1. We do not care about the order, so lets not bother if reorder > > > occurs, there are projects that follow this ( kafka) > > > 2. We do care, lets impose the rule going forward on any file we > > > touch, lets all get the formatter in place in IDE. > > > 3. We do care a lot, lets fix every file in the next few weeks. > > > 4. We do care, but lets not modify any existing file, but only > > > impose this on new files.( this means every developer diligently > > > uses a formatter and does not add code that does not follow the > > > sqoop style guide, it is based on mutual trust that this will > > > happen) > > > > > > > > > Each of the options has its merits and demerits that are obvious. > > > > > > The vote will close tomorrow evening. If there are no votes the > > > option is to go with #1, the least effort and max productivity in > > > getting things > > done. > > > > > > > > > > > > > > > Best, > > > *./Vee* > > > > >
