Yes, sorry, I replied to the wrong email... I meant to react to the proposal of:
- I want to make a meaningful change to Class A. - Class A is badly formatted. - I fix the formatting of Class A. - I commit Class A. - I make my meaningful change to Class A. - I commit Class A. I think steps #3 and #4 are a bad idea. Your endorsement of that workflow in http://mail-archives.apache.org/mod_mbox/incubator-river-dev/201012.mbox /%[email protected]%3e contradicts the "older sources" clause, I think. Chris -----Original Message----- From: Sim IJskes - QCG [mailto:[email protected]] Sent: Thursday, December 09, 2010 9:24 AM To: [email protected] Subject: Re: [VOTE] Re: Formatting of River Source Tree On 09-12-10 16:11, Christopher Dolan wrote: > and many (most?) of the files have a mix of both. So, I make the > counter-proposal that it's too late to fix this without a lot of > pointless code churn. I think we need to forbid formatting fixes that > just change tabs to spaces or vice versa. Even when done as separate > commits, those changes wreak havoc on diffs when trying to troubleshoot > regressions. I say developers just need to set their IDE to 8-chars for > tab for this project and live with it. Doesn't the older sources clause cover your proposal in broad lines? Do we need to be more specific? Gr. Sim Do you have r/o access to staging? In case you haven't: # Coding conventions ## Indentation Tabs are not used. Default indentation is 4 spaces. ## Other Contributors are advised to read <http://www.oracle.com/technetwork/java/codeconv-138413.html> and try to adhere as much as possible to these conventions. ## Older sources We do not actively search and reformat source files that are not formatted according to this convention. -- QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
