If you want to prevent mixed whitespace styles and whatnot, you can use EditorConfig <http://editorconfig.org/>.
On 28 April 2016 at 19:06, Gangumalla, Uma <uma.ganguma...@intel.com> wrote: > I am ok with a JIRA and type could be task for the reasons Sebb mentioned > below. > > But I prefer to keep 2 spaces if others also ok who is going to involve in > development. I assume most of Hadoop devs would have set their indentation > 2 already in their IDEs. So, here also most of them would involve with > indentation space 2 in their IDEs. If that does not hurt other, how about > keeping 2? > > It will make easy to identify the default tabs(tab with 4char space) from > IDEs like eclipse if code format settings are with 2 spaces. Ex: When some > new contributor forgot to modify their IDE setting with spaces, then code > will be easily identifiable if that has default setting with tabs. But > with 4 spaces, it will look same. > > I just read it from Commons site: (Copied from site > https://commons.apache.org/patches.html) > Respect The Original Style > Please respect the style of the orginal file. Make sure that your > additions fit in with that style. > Every component has coding conventions and every contribution is supposed > to adhere to them. You might find it a little difficult to discover the > conventions used by a particular component but if you stick to the style > of the original then that'll be fine. > If a patch is submitted which doesn't satisfy the component's coding > conventions, then either a committer will need to rewrite the submission > or it will be rejected. Getting it right in this first place will save you > having to rewrite it. > > It says that we can continue with original coding format if we want. But > anyway we can decide now. > > > > Regards, > Uma > > On 4/26/16, 3:06 AM, "sebb" <seb...@gmail.com> wrote: > > >On 26 April 2016 at 03:07, Chen, Haifeng <haifeng.c...@intel.com> wrote: > >> Hi Gary, > >> > >>>> Do you really want this level of Jira tracking? It seems over the top > >>>>to me. Is this process style for this component? In this case I would > >>>>just do it and not Jira it. Then for detailed history, you just look > >>>>at the commit history. Or are you just using Jira as a to-do list in > >>>>the early days of this component in its new home in Apache Commons? > >> As when we are working in Hadoop projects, we need a JIRA to start a > >>work and communicate with the community. I am not sure whether Apache > >>Commons allows commit of code without JIRA at this project stage. So I > >>just try to do it in a safe way in a new family:) > >> If Apache Commons folks thinks it's OK to do it without JIRA, I am OK > >>with it. > > > >If a developer spots a typo or missing/unclear Javadoc, I would say > >just fix it rather than raising a JIRA. > > > >This case is borderline to me since it affects the whole codebase. > >And the change impacts on how easy it is to see where/when changes were > >made. > >(This is more intrusive than a package name change at least as far as > >history is concerned since every line may be changed) > >Also it ideally needs to be co-ordinated with other changes. > > > >So I think it would be wrong to commit the change without some prior > >notification. > >This can either be a JIRA or agreement on the dev list. > > > >> Regards, > >> Haifeng > >> > >> -----Original Message----- > >> From: Gary Gregory [mailto:garydgreg...@gmail.com] > >> Sent: Tuesday, April 26, 2016 9:53 AM > >> To: Commons Developers List <dev@commons.apache.org> > >> Subject: RE: [crypto] The standard indentation is 4 spaces per indent > >> > >> Hi, > >> > >> Do you really want this level of Jira tracking? It seems over the top > >>to me. Is this process style for this component? In this case I would > >>just do it and not Jira it. Then for detailed history, you just look at > >>the commit history. Or are you just using Jira as a to-do list in the > >>early days of this component in its new home in Apache Commons? > >> > >> Gary > >> On Apr 25, 2016 6:47 PM, "Chen, Haifeng" <haifeng.c...@intel.com> > wrote: > >> > >>>>In our coding guidelines [1] we say that "The standard indentation is > >>>>4 > >> spaces per indent - but respect the number of spaces used by the > >>original." > >>>>The [crypto] Java code I've seen to far is all 2 spaces per indent. > >>>>I think now is the time to do this, most IDEs can do a one-shot format > >>>>of > >> a whole source tree. > >> Good catch, Gary. The original code was based on Hadoop format style > >>which is 2 spaces indent. I will fire a JIRA to format that. > >> > >> Thanks, > >> Haifeng > >> > >> -----Original Message----- > >> From: Gary Gregory [mailto:garydgreg...@gmail.com] > >> Sent: Tuesday, April 26, 2016 6:25 AM > >> To: Commons Developers List <dev@commons.apache.org> > >> Subject: [crypto] The standard indentation is 4 spaces per indent > >> > >> Hi all, > >> > >> In our coding guidelines [1] we say that "The standard indentation is 4 > >>spaces per indent - but respect the number of spaces used by the > >>original." > >> > >> The [crypto] Java code I've seen to far is all 2 spaces per indent. > >> > >> I think now is the time to do this, most IDEs can do a one-shot format > >>of a whole source tree. > >> > >> Gary > >> > >> [1] https://commons.apache.org/patches.html > >> > >> -- > >> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence > >>with Hibernate, Second Edition <http://www.manning.com/bauer3/> JUnit in > >>Action, Second Edition <http://www.manning.com/tahchiev/> > >> Spring Batch in Action <http://www.manning.com/templier/> > >> Blog: http://garygregory.wordpress.com > >> Home: http://garygregory.com/ > >> Tweet! http://twitter.com/GaryGregory > > > >--------------------------------------------------------------------- > >To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > >For additional commands, e-mail: dev-h...@commons.apache.org > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- Matt Sicker <boa...@gmail.com>
