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 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 smtp.lore.kernel.org (Postfix) with ESMTPS id 70FA2C433EF for ; Mon, 6 Dec 2021 16:30:43 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.239367.414881 (Exim 4.92) (envelope-from ) id 1muGsh-00072q-Nl; Mon, 06 Dec 2021 16:30:23 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 239367.414881; Mon, 06 Dec 2021 16:30:23 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1muGsh-00072j-Jw; Mon, 06 Dec 2021 16:30:23 +0000 Received: by outflank-mailman (input) for mailman id 239367; Mon, 06 Dec 2021 16:30:22 +0000 Received: from mail.xenproject.org ([104.130.215.37]) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1muGsg-00072d-GY for xen-devel@lists.xenproject.org; Mon, 06 Dec 2021 16:30:22 +0000 Received: from xenbits.xenproject.org ([104.239.192.120]) by mail.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1muGsd-0001i5-1Y; Mon, 06 Dec 2021 16:30:19 +0000 Received: from 54-240-197-239.amazon.com ([54.240.197.239] helo=[192.168.26.205]) by xenbits.xenproject.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.92) (envelope-from ) id 1muGsc-0000BA-Rg; Mon, 06 Dec 2021 16:30:18 +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" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=xen.org; s=20200302mail; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:From: References:Cc:To:Subject:MIME-Version:Date:Message-ID; bh=DjieWqTnLrf40ufKV94QEKNdBFHfPiZqhGkuQwuhFHQ=; b=HMK5m0A7v/WyadltEXHxtI4T3k /oCrc75Q1YkMhuNnt8Osvb3x+Y7OLT9mtf6QFirX8V3uTs+PSxce5cubDcZtcrmvn8iB+DdFsOmEm QxiHavr2f7Ak4zajf+NbtXp6U6Ah4utntb59IX72j7KP4F2POoJrAq5lcM6FhdGmZeQI=; Message-ID: <5612585c-f650-18e9-676e-58dffb68280b@xen.org> Date: Mon, 6 Dec 2021 16:30:17 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.3.2 Subject: Re: [PATCH 1/7] xz: add fall-through comments to a switch statement To: Jan Beulich Cc: Andrew Cooper , George Dunlap , Stefano Stabellini , Wei Liu , "xen-devel@lists.xenproject.org" , Ian Jackson References: <0ed245fa-58a7-a5f6-b82e-48f9ed0b6970@suse.com> <0c0e67f3-5e0a-f047-ca09-1cf078e6b094@suse.com> <71ef250c-be92-2b2f-0f07-ce32c17d8050@xen.org> <0b808ce0-23a2-65ae-dfb3-b167d5565b31@suse.com> <6bcd1555-ee0d-dd6d-55ca-0ca0e64c3623@xen.org> <24992.55453.893877.246946@mariner.uk.xensource.com> <2b4195da-21a8-6c30-27c8-43e943b821a1@suse.com> <53cd2f84-f011-9c97-a108-fd946535920b@xen.org> <5a6ffa5a-6884-57b5-c296-904e9b0b4c78@suse.com> <9affccd1-0f74-c58e-ebd4-5a5546ec80b1@xen.org> <1a708488-efff-114f-0693-c9772b5ff9b2@suse.com> From: Julien Grall In-Reply-To: <1a708488-efff-114f-0693-c9772b5ff9b2@suse.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 06/12/2021 16:24, Jan Beulich wrote: > On 06.12.2021 17:21, Julien Grall wrote: >> On 06/12/2021 16:12, Jan Beulich wrote: >>> On 06.12.2021 17:06, Julien Grall wrote: >>>> On 06/12/2021 15:06, Jan Beulich wrote: >>>>> On 06.12.2021 15:28, Julien Grall wrote: >>>>>> I am not going to ack it but I am also not going to Nack it if another >>>>>> maintainer agrees with your approach. >>>>> >>>>> FTAOD I'll be giving it a week or so, but unless I get an outright NAK, >>>>> I'm now in a position to put this in with Luca's R-b. >>>> >>>> From the check-in policy section in MAINTAINERS: >>>> >>>> 4. There must be no "open" objections. >>>> >>>> So I think this cannot be check-in given two maintainers disagree on the >>>> approach. That said, as I wrote earlier my condition for not Nacking is >>>> another maintainer agree with your approach. >>> >>> Hmm, I did address both your and Ian's concerns in v2, admittedly by only >>> going as far as minimally necessary. I therefore wouldn't call this an >>> "open objection". >> >> I believe my objection is still open. I still have have no way to verify >> what you did is correct. >> >> For instance, the tags in patch #2 are: >> >> Link: http://lkml.kernel.org/r/20191104185107.3b6330df@tukaani.org >> Reported-by: Yu Sun >> Signed-off-by: Lasse Collin >> Acked-by: Daniel Walker >> [Linux commit: 8e20ba2e53fc6198cbfbcc700e9f884157052a8d] >> >> The tags in the Linux commit are: >> >> Signed-off-by: Lasse Collin >> Reported-by: Yu Sun >> Acked-by: Daniel Walker >> Cc: "Yixia Si (yisi)" >> Signed-off-by: Andrew Morton >> Signed-off-by: Linus Torvalds >> >> * The first two matches the original e-mails >> * I couldn't find the 3rd on the ML. >> * The Cc could be ignored >> * The signed-off-by are I guess what you call "mechanical" > > Am I understanding right that now you're complaining about me > having retained one tag too many? So far all discussion was about > too few tags. I am complaining on the fact that this is really difficult to figure out how you decided which tags to keep. I will repeat what I said before, it should have been so much easier if you just copied/pasted the one from the Linux commit. Cheers, -- Julien Grall