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.3 required=3.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,HTML_MESSAGE,MAILING_LIST_MULTI, MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=ham 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 79BA8C43603 for ; Mon, 9 Dec 2019 10:13:20 +0000 (UTC) Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (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 46901206D5 for ; Mon, 9 Dec 2019 10:13:20 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="t7frp0+K" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 46901206D5 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=gmail.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Received: from localhost ([::1]:38150 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieG2Z-00048E-Ga for qemu-devel@archiver.kernel.org; Mon, 09 Dec 2019 05:13:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52257) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ieG1y-0003je-7w for qemu-devel@nongnu.org; Mon, 09 Dec 2019 05:12:43 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ieG1w-0001Cc-P5 for qemu-devel@nongnu.org; Mon, 09 Dec 2019 05:12:42 -0500 Received: from mail-oi1-x22d.google.com ([2607:f8b0:4864:20::22d]:38265) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ieG1w-0001C7-J2 for qemu-devel@nongnu.org; Mon, 09 Dec 2019 05:12:40 -0500 Received: by mail-oi1-x22d.google.com with SMTP id b8so5819585oiy.5 for ; Mon, 09 Dec 2019 02:12:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4b0Wi+UuNHKGxE3MUTu5fMGeOASZbL+V6haBStvTEk4=; b=t7frp0+KyjVUMm2jZcBPq8XhDQLKTgSgZXY9ML+5OqECBPp9KMsA3UabRXj0xgTcrI dCzxGhDgK3cbDg5Og4W8SoE3oET82AY4i/ptzFrTzR+vhii9XzPeoPo/J5cKD0xVNgaa AmSV04JEtlWvFEjg2tAKFg5PxrGbL2AwvpOwLIhdCVgJWmtOFZn0KcWYCzNws5lDXbnk SVHcxCSXlJ5eKemoLBhNboeAOUH3VoAVhyK86G9OhhXb7JiwygaqCdTtzLqVLuv+yj5x OoKpomeM7SxgEpw/rfkxNPoAmoVISaMyt5ZPQ5pU+W6GYHmVQ3BeEIQ4k6ckCPBEShRz eonQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=4b0Wi+UuNHKGxE3MUTu5fMGeOASZbL+V6haBStvTEk4=; b=UQVrBN45Qp5OqEgDpcMPOpc5zVExjULLmhqQfcFXRt6SR1SqMaeGm00spJPIthWTPg a5eErLpFoNcxdUxWPCEVm11ehuP7jZLSzK9FnldO/hVPyVx1Km6kIhnATjrNWCtDC35D hWnQcwIpijMh/nQWfwPaJoSQKjN4hIBotWdVVr4yIentJvVhObUKLUBgLMT00EYp2xHK /+0XTBBplfOFedRp95R+9nitLJ9EslxEWNDWf0a/XREQemq7TbtOZMBcSoUhzgHmFc04 TaP4IBez6kkt7mF58tUEQibhemSMR3K2QqmZ7ARPCWUyA3qYBsO943X3AIFc04XYTp8E GrgA== X-Gm-Message-State: APjAAAVpc7s6/YAZug1EoJmsJXHDhmZPVe7OZqLw0LYYdJvnxoGEcAgO iU7dYgBwRLFcZpUHbEqufNN831YezP6Cj1ar4zw= X-Google-Smtp-Source: APXvYqwYCNnb1zmEfLXhg7S5p00IWrKObXjHMCDko0Ru72o00qUs2n1cTCScJeQWEP7xyiSE98lxCp/REQfceMJkjbk= X-Received: by 2002:a05:6808:98b:: with SMTP id a11mr23788673oic.62.1575886359629; Mon, 09 Dec 2019 02:12:39 -0800 (PST) MIME-Version: 1.0 Received: by 2002:a9d:d21:0:0:0:0:0 with HTTP; Mon, 9 Dec 2019 02:12:39 -0800 (PST) In-Reply-To: <9f71601e-de90-86d9-7c6b-352d923bbc06@redhat.com> References: <4cbaadf8-ae4f-d086-2137-b83d61a5e9a5@redhat.com> <9f71601e-de90-86d9-7c6b-352d923bbc06@redhat.com> From: Aleksandar Markovic Date: Mon, 9 Dec 2019 11:12:39 +0100 Message-ID: Subject: Re: [RFC] Use of the Nacked-by tag by CI scripts To: Paolo Bonzini Content-Type: multipart/alternative; boundary="000000000000ac12c6059942a240" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::22d X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , =?UTF-8?Q?Philippe_Mathieu=2DDaud=C3=A9?= , qemu-devel , Stefan Hajnoczi , Cleber Rosa , =?UTF-8?B?QWxleCBCZW5uw6ll?= Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" --000000000000ac12c6059942a240 Content-Type: text/plain; charset="UTF-8" On Monday, December 9, 2019, Paolo Bonzini wrote: > On 09/12/19 10:28, Aleksandar Markovic wrote: > > If there is a consensus about using this tag, the following patch > > can be added to Peter's management scripts: > > https://git.linaro.org/people/pmaydell/misc-scripts.git/ > > > > > > I always assumed that pull requests by sub-maintainers should contain > > "ready for merging" code (justified, reviewed, tested, ...). Why would > > ever a sub-maintainer send something that doesn't comply to these > > conditions? > > Because things can and do go wrong, perhaps someone was on vacation > while the original patch was posted, perhaps somebody is giving a > negative review outside his maintenance area, perhaps there would be > conflicts with a tree-wide series being discussed elsewhere... It's > rare and I don't think it would be misused, but I think it's a good idea > to have a machine-readable way to block patches. > > I'm afraid this would be opening a Pandora's box. For such rare cases, a message from a person: "Please hold on this patch until I am back from vacation.", "Please wait until I merge my series acting on the same files", or similar, would perfectly do the job, as it did in the past. We are fixing something that is not broken. > However, I'm not sure why the commits would contain a tag. Instead, we > could use the patchew REST API > (https://patchew.org/api/v1/projects/1/series/MESSAGE-ID/) and search > for nacked-by tags in there. > > Paolo > > > I think, in general, this tag would do more harm than good, allowing > > frivolous blocking of patches, and fixing a process that already works, > > without any need. > > --000000000000ac12c6059942a240 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Monday, December 9, 2019, Paolo Bonzini <pbonzini@redhat.com> wrote:
On 09/12/19 10:28, Aleksandar Markovic wrote:
>=C2=A0 =C2=A0 =C2=A0If there is a consensus about using this tag, the f= ollowing patch
>=C2=A0 =C2=A0 =C2=A0can be added to Peter's management scripts:
>=C2=A0 =C2=A0 =C2=A0https://git.linaro.org/people/pmay= dell/misc-scripts.git/
>=C2=A0 =C2=A0 =C2=A0<https://git.linaro.org/people/= pmaydell/misc-scripts.git/>
>
> I always assumed that pull requests by sub-maintainers should contain<= br> > "ready for merging" code (justified, reviewed, tested, ...).= Why would
> ever a sub-maintainer send something that doesn't comply to these<= br> > conditions?

Because things can and do go wrong, perhaps someone was on vacation
while the original patch was posted, perhaps somebody is giving a
negative review outside his maintenance area, perhaps there would be
conflicts with a tree-wide series being discussed elsewhere...=C2=A0 It'= ;s
rare and I don't think it would be misused, but I think it's a good= idea
to have a machine-readable way to block patches.


I'm afraid this would be opening a= Pandora's box. For such rare cases, a message from a person: "Ple= ase hold on this patch until I am back from vacation.", "Please w= ait until I merge my series acting on the same files", or similar, wou= ld perfectly do the job, as it did in the past.

We= are fixing something that is not broken.
=C2=A0
However, I'm not sure why the commits would contain a tag.=C2=A0 Instea= d, we
could use the patchew REST API
(https://patchew.org/api/v1/projects/1/series/MESSAGE-ID/<= /a>) and search
for nacked-by tags in there.

Paolo

> I think, in general, this tag would do more harm than good, allowing > frivolous blocking of patches, and fixing a process that already works= ,
> without any need.

--000000000000ac12c6059942a240--