From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60510) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rw8ta-0008IV-8f for qemu-devel@nongnu.org; Sat, 11 Feb 2012 04:05:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rw8tZ-0007oQ-38 for qemu-devel@nongnu.org; Sat, 11 Feb 2012 04:05:26 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:40895) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rw8tZ-0007oJ-02 for qemu-devel@nongnu.org; Sat, 11 Feb 2012 04:05:25 -0500 Received: by iahk25 with SMTP id k25so1663218iah.4 for ; Sat, 11 Feb 2012 01:05:24 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <4F329385.4030203@codemonkey.ws> References: <4F324A60.7070600@samsung.com> <4F326D66.6060808@suse.de> <4F329385.4030203@codemonkey.ws> From: Blue Swirl Date: Sat, 11 Feb 2012 09:05:03 +0000 Message-ID: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] Restore consistent formatting List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Dmitry Solodkiy , =?UTF-8?Q?Andreas_F=C3=A4rber?= , Evgeny Voevodin , qemu-devel@nongnu.org On Wed, Feb 8, 2012 at 15:23, Anthony Liguori wrote= : > On 02/08/2012 09:04 AM, malc wrote: >> >> On Wed, 8 Feb 2012, Andreas F?rber wrote: >> >>> malc, >>> >>> Arbitrarily reformatting your files is not okay. If you want a differen= t >>> formatting, you need to fix checkpatch.pl first to not error on that >>> formatting in your files. >> >> >> It was always formatter like this (internally consistent), then others >> added code which made it not so. > > > We do have a mixed style in the audio layer. =C2=A0I'm not happy about th= at but I > also feel strongly that going through and doing a reformat is not a > worthwhile exercise. > > I can also understand the desire to keep things consistent. =C2=A0But pat= ches > should always go to the mailing list. =C2=A0I certainly would have acked = such a > patch FWIW. Really? First, this would imply that local consistency is more important to you than global consistency and second, pure reformatting patches are now acceptable to you (despite previous git blame breakage reasoning). What would your reaction be if I declared that CODING_STYLE for target-sparc/* is Linux kernel one (some pieces could probably be found which would comply even now to make the precedent case for argument's sake) and post a reformatting patch to the list? > I think people get a bit too excited about coding style. =C2=A0There are = much > more important things to worry about in life than the number of spaces > before a parenthesis :-) In general, a coding style is one aspect of development guidance. The level of guidance can vary, it could be missing, there could be a loose convention, a guideline or even a iron hard rule. It could apply differently case by case or globally. In case of coding style, I'd strongly prefer that the level of guidance is clear to everyone and it doesn't change very often. As to the actual content of the guidance, that can never be precise. In this specific case, CODING_STYLE says nothing about spaces after function identifiers. However, vast majority of code omits them. Spaces are used in GNU style, not in K&R or Linux style and I think QEMU style is closer to them than to GNU style. I'd say this case is not unlike the previous cases where braces were added to code where there were none before, so reformatting is going backwards (unless local consistency is given priority). Personally I prefer strong, enforced rules to loose conventions but it's more important to me that everybody in a project plays by the same rules (or agrees to lack of them), whatever they are. Personally I also hate GNU style and would prefer that malc would swallow his pride and reformat audio etc. to match rest of the world, but I respect his status as taking responsibility for maintaining the audio layer. > Regards, > > Anthony Liguori > >> >> [..snip..] >> >