From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 00E05A0C47 for ; Tue, 12 Oct 2021 08:44:56 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id EDC6240E0F; Tue, 12 Oct 2021 08:44:55 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 0ECD440E01 for ; Tue, 12 Oct 2021 08:44:54 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 653B25C00E2; Tue, 12 Oct 2021 02:44:53 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 12 Oct 2021 02:44:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= ynE1PB7PK5E8+5wJ3zSJvXgHTnP70DV1sBg7/Q9fDAI=; b=RbTBpoBC1co4db5H QZur1pxw9MwSFxxjCMkdP+S8YxNmCfliGJ385P+3T+XanLkDcyvIeNVtsS22Dmvu ILdpFcMhf+Tz1AoR/FL08QSqrz5kYyUmpERWi9PVK1+s2Xh1j+YhKcjbv4Qvwp0U Dhdt0XrbxamV4wJhXe3CmmF2eNqbj5TGi7AyMy/P8xQYkw307Y2gJf/L9U85TeHB KQ9IZ5cD7+bLfqbNb7GkMWGD1hbRRn6DOe94VO5bXG26PpJWx3RCuyV6Ao3UErLd J7jn5HC/sWAfjkENUZGlK/BdLyCBgFTmeSkAnxVwXp1P0dQkaGF1MTE/zWgBjewL oqo8ug== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=ynE1PB7PK5E8+5wJ3zSJvXgHTnP70DV1sBg7/Q9fD AI=; b=P1w6t7h+4JzcEt0oowG3jNS24cpL2+UdbJszTy+BoJ+WykCC/Moz8C2Kp 4qqAQOGDZ+gBMHL/nbuFoAtFAcsVc/T4aC2A2N9Ah8AAuDOPpSF+xjMuRLQ3AW69 VnDdP2aAINvUW63Cpa2O66EG6nk29sfqMiH5m092r9aBL5TZ+nzK5WyFzJCbA170 frVzUKYOpp1BsoyiuRopItSkh6I1mTc80QRMeU4mqiLpcdmtmPUFk2OFVxk36yWd 8ChE39t/KbGjezOGKMGVSgEoLapASJWNVNvcwpS9hYv1x2SywiLdNWJMLK2VKsqb V0S4M0lDUsk31GJuthoLbHrvFw7YQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtjedguddutdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 12 Oct 2021 02:44:50 -0400 (EDT) From: Thomas Monjalon To: Ali Alnubani Cc: "ci@dpdk.org" , "jerinj@marvell.com" , "ferruh.yigit@intel.com" , "david.marchand@redhat.com" , "juraj.linkes@pantheon.tech" Date: Tue, 12 Oct 2021 08:44:47 +0200 Message-ID: <2024535.ONPTUEBfDP@thomas> In-Reply-To: References: <20210906154537.1299-1-alialnu@nvidia.com> <2586128.JSg8es4y6H@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-ci] [PATCH v2 10/10] tools: skip the IDs we already fetched X-BeenThere: ci@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK CI discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ci-bounces@dpdk.org Sender: "ci" 11/10/2021 21:30, Ali Alnubani: > From: Thomas Monjalon > > 21/09/2021 16:35, alialnu@nvidia.com: > > > From: Ali Alnubani > > > > > > Store the IDs we already fetched in a file and don't > > > run 'callcmd' again for them. > > > > We store all IDs. Should we manually remove olds one from time to time? > > > > Do you have a suggestion for when should we clear this file? Maybe each time the script starts? Yes at each start, we can remove the very old entries, like more than 10 hours old. > > We need an explanation about the strategy, why it is needed. > > I think it is because filtering by date is not enough. > > In order to not miss any patch, we should request a date earlier > > than the previous fetch and skip those already fetched. > > The reason this change was made isn't because filtering by date is not enough, it's because > I want to avoid feeding the same ID to 'callcmd' more than once. > This can happen if a patchwork ID was created between recording date_now and fetching the API. > I don't think we are missing any IDs, even without this change. > > > Where the "earlier date" is defined? > > There are 2 variables, "date_now", which is recorded right before fetching from the API, and then gets written > to the file, and "since", which is the last date that was written to the file. OK please update the commit log.