From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.6 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id CA185C433DF for ; Mon, 19 Oct 2020 18:08:22 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 4F18F2225F for ; Mon, 19 Oct 2020 18:08:22 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="bcllUHHW" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 4F18F2225F Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.8802.23655 (Exim 4.92) (envelope-from ) id 1kUZZi-0006W9-SO; Mon, 19 Oct 2020 18:08:02 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 8802.23655; Mon, 19 Oct 2020 18:08:02 +0000 X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kUZZi-0006W2-OY; Mon, 19 Oct 2020 18:08:02 +0000 Received: by outflank-mailman (input) for mailman id 8802; Mon, 19 Oct 2020 18:08:01 +0000 Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kUZZh-0006Vx-BN for xen-devel@lists.xenproject.org; Mon, 19 Oct 2020 18:08:01 +0000 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id eb2e32d7-0909-4613-b0fb-644524ccc002; Mon, 19 Oct 2020 18:08:00 +0000 (UTC) Received: from sstabellini-ThinkPad-T480s (c-24-130-65-46.hsd1.ca.comcast.net [24.130.65.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 34FB62225F; Mon, 19 Oct 2020 18:07:59 +0000 (UTC) Received: from us1-rack-iad1.inumbo.com ([172.99.69.81]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1kUZZh-0006Vx-BN for xen-devel@lists.xenproject.org; Mon, 19 Oct 2020 18:08:01 +0000 X-Inumbo-ID: eb2e32d7-0909-4613-b0fb-644524ccc002 Received: from mail.kernel.org (unknown [198.145.29.99]) by us1-rack-iad1.inumbo.com (Halon) with ESMTPS id eb2e32d7-0909-4613-b0fb-644524ccc002; Mon, 19 Oct 2020 18:08:00 +0000 (UTC) Received: from sstabellini-ThinkPad-T480s (c-24-130-65-46.hsd1.ca.comcast.net [24.130.65.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 34FB62225F; Mon, 19 Oct 2020 18:07:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1603130879; bh=szW4QMEKptLRzsjukhcSstsKndsQNBu+FwXo2aGT3yw=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=bcllUHHWhF30+zcpO3aScHmBmlfHyB90la0fdxkI1lRLJjWsPig/FTkXaC3jxvvQb QufqyJwSmKDJfkylWbhppgE5BrqqhPaACjawDCZuf79v4wJk+5IXSL11bBWzq+Rpp2 pBUPunZZE8Ozhw5GOpXGoEuyAsijF4tK6O30FLJM= Date: Mon, 19 Oct 2020 11:07:58 -0700 (PDT) From: Stefano Stabellini X-X-Sender: sstabellini@sstabellini-ThinkPad-T480s To: Artem Mygaiev cc: Julien Grall , Anastasiia Lukianenko , "jbeulich@suse.com" , "George.Dunlap@citrix.com" , "vicooodin@gmail.com" , "xen-devel@lists.xenproject.org" , "committers@xenproject.org" , "viktor.mitin.19@gmail.com" , Volodymyr Babchuk Subject: RE: Xen Coding style and clang-format In-Reply-To: Message-ID: References: <300923eb27aea4d19bff3c21bc51d749c315f8e3.camel@epam.com> <4238269c-3bf4-3acb-7464-3d753f377eef@suse.com> <3ff3f7d16cdab692178ce638da1a6b880817fb7e.camel@epam.com> <64FE5ADB-2359-4A31-B1A1-925750515D98@citrix.com> <4d4f351b152df2c50e18676ccd6ab6b4dc667801.camel@epam.com> <5bd7cc00-c4c9-0737-897d-e76f22e2fd5b@xen.org> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: multipart/mixed; BOUNDARY="8323329-844236279-1603130502=:12247" Content-ID: This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323329-844236279-1603130502=:12247 Content-Type: text/plain; CHARSET=UTF-8 Content-Transfer-Encoding: 8BIT Content-ID: On Fri, 16 Oct 2020, Artem Mygaiev wrote: > -----Original Message----- > From: Julien Grall > Sent: пятница, 16 октября 2020 г. 13:24 > To: Anastasiia Lukianenko ; jbeulich@suse.com; George.Dunlap@citrix.com > Cc: Artem Mygaiev ; vicooodin@gmail.com; xen-devel@lists.xenproject.org; committers@xenproject.org; viktor.mitin.19@gmail.com; Volodymyr Babchuk > Subject: Re: Xen Coding style and clang-format > > > Hi, > > > > On 16/10/2020 10:42, Anastasiia Lukianenko wrote: > > > Thanks for your advices, which helped me improve the checker. I > > > understand that there are still some disagreements about the > > > formatting, but as I said before, the checker cannot be very flexible > > > and take into account all the author's ideas. > > > > I am not sure what you refer by "author's ideas" here. The checker > > should follow a coding style (Xen or a modified version): > > - Anything not following the coding style should be considered as > > invalid. > > - Anything not written in the coding style should be left > > untouched/uncommented by the checker. > > > > Agree > > > > I suggest using the > > > checker not as a mandatory check, but as an indication to the author of > > > possible formatting errors that he can correct or ignore. > > > > I can understand that short term we would want to make it optional so > > either the coding style or the checker can be tuned. But I don't think > > this is an ideal situation to be in long term. > > > > The goal of the checker is to automatically verify the coding style and > > get it consistent across Xen. If we make it optional or it is > > "unreliable", then we lose the two benefits and possibly increase the > > contributor frustration as the checker would say A but we need B. > > > > Therefore, we need to make sure the checker and the coding style match. > > I don't have any opinions on the approach to achieve that. > > Of the list of remaining issues from Anastasiia, looks like only items 5 > and 6 are conform to official Xen coding style. As for remainning ones, > I would like to suggest disabling those that are controversial (items 1, > 2, 4, 8, 9, 10). Maybe we want to have further discussion on refining > coding style, we can use these as starting point. If we are open to > extending style now, I would suggest to add rules that seem to be > meaningful (items 3, 7) and keep them in checker. Good approach. Yes, I would like to keep 3, 7 in the checker. I would also keep 8 and add a small note to the coding style to say that comments should be aligned where possible. --8323329-844236279-1603130502=:12247--