From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 459AF3858D38 for ; Tue, 20 Sep 2022 10:34:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 459AF3858D38 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1663670041; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zgjncQEYHRoxhLfeTfaObdr+D+22lFWb5TKyrUBIYAE=; b=Q0jKcFpO8l61ykPo9w3sFAxAZlgrfzY/jp54zzyIzoIep8RfQeqypsg1NIkxaRURhq7EDo VBLkpRUFfJDwtjRTvshX4Eu2s9eg270cvozabOHCfhJlGM4tyVNzuhVNb00xKpvVrgdyyv w0Cav+hJDtUh4guVguMKHL3F8bjs808= Received: from mail-il1-f198.google.com (mail-il1-f198.google.com [209.85.166.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-540-i8GuzCK4Obe6dbuLMo34VA-1; Tue, 20 Sep 2022 06:34:00 -0400 X-MC-Unique: i8GuzCK4Obe6dbuLMo34VA-1 Received: by mail-il1-f198.google.com with SMTP id h5-20020a056e021d8500b002eb09a4f7e6so1328101ila.14 for ; Tue, 20 Sep 2022 03:34:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date; bh=zgjncQEYHRoxhLfeTfaObdr+D+22lFWb5TKyrUBIYAE=; b=huXw15vVM2HNegG8n9yhy6xeOk/H9moNfIq889R0C0zEDj6hk+WQnQ0zBGRv0u6aYz WBQN23GDbvcWvCa+2abNpZl22PZcpYGjOuTXLHp8ETDRvX/NDOmoRp1sLzeCdaZq8E+4 2wlnz+Io40j7GmRW4IMTrMJYlc2LU9pYe/ga+elcEUnrhvREh3uC/mbW2E+io+/qO9PO EMAQbjYusfjd0nWSwrOImLygsCsB6A7o+baj+YFPj4tedeE2+xcjM5it9dCW7co55EPB XCtyIedECAYGCzuxqdSP72aCfxQQzmmB5a4DBityQOhT/iECMPutjE3qqOA6IKF33p64 NR0g== X-Gm-Message-State: ACrzQf0l3vgqqmA93+IT5diDYRHh7EC0N3tLj03/fi9xLaExsRV6f1sP AXsCUb+KmbwLSf9em1bZb8mBvZGC6GdF+3PhmUMmnle8bBHmzrpj1l4BinWcTVuwXuQu9WDZXEE 4daKOQCy+oDZxNUAt7UE6 X-Received: by 2002:a02:7b26:0:b0:351:7457:5ce3 with SMTP id q38-20020a027b26000000b0035174575ce3mr9930670jac.177.1663670039662; Tue, 20 Sep 2022 03:33:59 -0700 (PDT) X-Google-Smtp-Source: AMsMyM4xfk/lFzxadzXNMs1NWkm2pZ6vyeicYifB0qCoe3VxRoj2gJNjEYLcUvBcIgiExq/5NOp8xw== X-Received: by 2002:a02:7b26:0:b0:351:7457:5ce3 with SMTP id q38-20020a027b26000000b0035174575ce3mr9930663jac.177.1663670039416; Tue, 20 Sep 2022 03:33:59 -0700 (PDT) Received: from fedora ([104.129.159.227]) by smtp.gmail.com with ESMTPSA id i43-20020a02602b000000b0034f465bbd52sm501902jac.42.2022.09.20.03.33.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 20 Sep 2022 03:33:58 -0700 (PDT) Date: Tue, 20 Sep 2022 06:33:56 -0400 From: Carlos O'Donell To: Siddhesh Poyarekar Cc: GNU C Library Subject: Re: New patchwork state: Invalid Message-ID: References: <931e9495-092f-e3df-317d-3e674ac789a8@gotplt.org> MIME-Version: 1.0 In-Reply-To: <931e9495-092f-e3df-317d-3e674ac789a8@gotplt.org> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, Sep 19, 2022 at 05:49:30PM -0400, Siddhesh Poyarekar wrote: > Adhemerval, Florian and I noticed a couple of manpage patches during review > that managed to apply to the glibc tree because they only added new files > and as a result, didn't fail CI. I've added a new terminal state 'Invalid' > to patchwork to mark such patches from now on. It should be used for any > patches that don't belong to glibc, e.g. because they've been cross-posted. I noticed this too! I asked DJ aobut his and he said it was common. I'm OK with "Invalid" but I would rather go with "Not applicable" because the patch is *valid* but not applicable. Total bikeshed. > This is now separate from the 'Fails to apply' state, which was previously > overloaded to indicate non-glibc patches. Our maxim should be: As few states as possible. My opinion is that we should not have "Fails to apply." Instead the state should always be "Failed CI." Applying a patch is a lower level operation that is related to pre-commit CI. The flow could be like this: - A patchwork bot attempts to re-apply the patch, and if it fails it creates a "fail" entry in the CI which reads "Rebase bot failed". - A patchwork bot notices the fail and marks the patch or whole series as "Failed CI" My suggestion is as follows: - Remove "Fails to apply." from the workflow. As few states as possible should be our goal. - Suggest renaming "Invalid" to "Not applicable" only because it sounds kinder (complete bikeshed). Cheers, Carlos.