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 0BE6545AE8; Tue, 8 Oct 2024 21:50:34 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id ABDB340E11; Tue, 8 Oct 2024 21:50:33 +0200 (CEST) Received: from mail-pl1-f182.google.com (mail-pl1-f182.google.com [209.85.214.182]) by mails.dpdk.org (Postfix) with ESMTP id A10F34064E for ; Tue, 8 Oct 2024 21:50:31 +0200 (CEST) Received: by mail-pl1-f182.google.com with SMTP id d9443c01a7336-20b49ee353cso56434825ad.2 for ; Tue, 08 Oct 2024 12:50:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1728417031; x=1729021831; darn=dpdk.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=hz01Y7XW9SFGy5v3NLVPAFfP6k9hAogPmEG3pFUEe6g=; b=LcSIc5P4fZddfdU9ZcI1mmUUcjRIJbuIf1GCsW2fGZl+PE5t8Pwh/n3w0PYkLRFqPK kclODL59lt77Q/MXdPTF4M/gAneS+9tUToS3NYbUzy4Gd6qqKD5evgdviXzunI91Z9oe 0SqqBC/3ztUO1gclLSUKYE/ZAySICqlxoE/mg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1728417031; x=1729021831; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=hz01Y7XW9SFGy5v3NLVPAFfP6k9hAogPmEG3pFUEe6g=; b=NhLX8/Plas+DwI7okKQdEp/UroXO45r6vxfsOaCycX7oXPge7EwVo/0MJ8mGSFRBZi ZAria4U3xpQ91dPHIn04H1HT7IEtpgbgCg1Zf+6EFfJg1cBPt6MKZUcRuTwp0579sSUi fO/aJxgHd7cdL0a+6/Enq0zq3V4tTcEBEktJoYqrS49wJiDnhqmlXidogGb8xeCInkeX gVGSMtk8J79xwseJFW9I7AfD2ziwANJxgSRrE0ML4sS6A0Vaoxp84R4dJmxvX53boaTa rTO/56CUjljaR9y+iQ7ffxdua7MQNrfXKhKfCKN5dLCfDNgfYdzDvYAEiIrqEc+CsOVU KRqA== X-Forwarded-Encrypted: i=1; AJvYcCWyQblGCQGK1uOH2kSzEbrjoWAWDdTFp9AFQADbb4og6b5jhSdv5OjqcmIOfx5BBWyj6HA=@dpdk.org X-Gm-Message-State: AOJu0YxxQQ46Ys7x5tdaaBTcdxmYMYk5IVZ8p7f/WR+bPdLbYl+yQPwT KIRXaKTyWmu6d49QGX1j86lRF1mf3cXGOmAN1zSdDATm38Oy6s9JYQzh0D6bhk9ZqpxNf4gIZl2 XT62x3heRLb28hhVD16/k/2KvwFcNWNSC7IM1TQ== X-Google-Smtp-Source: AGHT+IF7H41yBEJ3Tq9lm5Dh6Gi4Ejv14JKaVwh3WfBj8rTwfZLNKQtEnSYNl2QRSUs8Kmur/o+KYAbj4bZZ5Q6xj9I= X-Received: by 2002:a17:902:e743:b0:20c:59ca:d76e with SMTP id d9443c01a7336-20c636f44a2mr2167005ad.8.1728417030764; Tue, 08 Oct 2024 12:50:30 -0700 (PDT) MIME-Version: 1.0 References: <20240920125737.1197969-1-bruce.richardson@intel.com> In-Reply-To: From: Patrick Robb Date: Tue, 8 Oct 2024 15:49:12 -0400 Message-ID: Subject: Re: [OS-Team] [dpdklab] Re: [PATCH 0/5] Increase minimum meson version To: David Marchand Cc: dpdklab , Min Zhou , dev@dpdk.org, mb@smartsharesystems.com, thomas@monjalon.net, ci@dpdk.org, Bruce Richardson , "Puttaswamy, Rajesh T" , Cody Cheng , Adam Hassick Content-Type: multipart/alternative; boundary="000000000000249a3f0623fc73e3" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --000000000000249a3f0623fc73e3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 8, 2024 at 4:28=E2=80=AFAM David Marchand wrote: > > This series can't be merged until the (UNH and LoongArch) CI are ready > for such a change. > > TL;DR: the meson minimum version is being changed from 0.53.2 to 0.57 > in the current release. > > @UNH @Min Zhou > How long would it take for all CI to be ready for this change? > > Thanks for the heads up. So, as far as I can tell, this will require an update to the dpdk/.ci/linux-setup.sh script (which I have just submitted) as I think various labs rely on it including the github robot, loongson, Intel (Maybe, I don't know). UNH does not use it much as we opt to meet the meson dependency separately in the dpdk-ci project's container template engine. It will also require updates to the container template engine, which I can get Cody started on tomorrow. > Important note: if relevant to your CI, testing against LTS branches > must still be done with the 0.53.2 version, so no change relying on > post 0.53.2 meson feature gets backported. > Okay, full disclosure I don't think this is something we handled the last time the meson version got bumped in 2022. So, back then we just bumped the meson version for all environments to .53, then did LTS testing for 19.11, 20.11, 21.11 from environments running meson .53. But, I understand how this is an issue and something we should avoid this go around. However, it is not ideal to set the meson version "at runtime" for CI testing based on the repo under test (mainline and next-* want .57, old LTS versions want .53). It would be possible to modify our jenkinsfiles (automation scripts) to check the DPDK version, and run pip commands resetting the meson version accordingly, at the start of each testing job... but I have a couple concerns here with regards to stability/maintenance. Another option, which Adam is suggesting, is to create a dedicated environment which is version locked to .53 (it can just be an ubuntu container image), label it as a meson .53 environment, and add that to the total list of dpdk build environments which are run when we do testing for either 22.11, or 23.11. Then, we could run the rest of the testing from the same container images we use for mainline (that have .57 baked in), and this would not be a problem because we would have that 1 environment doing a dpdk build, which is guaranteed to be on .53. Bruce/David let me know if you can think of any issues with this. This is also very similar to a Community Lab request from a few months ago (which we have an open internal Jira ticket for), which is to add a VM environment which is locked to the minimum supported kernel version for DPDK. But, that's another story... Anyways, in terms of the timeline... the Jenkins script updates are probably the most difficult in that they will require a PR review, dry run tests etc. but it's still fairly trivial. Cody can probably update the meson dependencies on the template engine and submit that to the dpdk-ci project by end of week. So, I would say CI should be ready by next Tuesday, provided the patches which will be incoming to dev and ci mailing lists can be merged. Is this timeline okay? --000000000000249a3f0623fc73e3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Oct 8, 2024 at 4:28=E2=80=AFA= M David Marchand <david.mar= chand@redhat.com> wrote:

This series can't be merged until the (UNH and LoongArch) CI are ready<= br> for such a change.

TL;DR: the meson minimum version is being changed from 0.53.2 to 0.57
in the current release.

@UNH @Min Zhou
How long would it take for all CI to be ready for this change?


Thanks for the heads up. So, as far as= I can tell, this will require an update to the dpdk/.ci/linux-setup.sh scr= ipt (which I have just submitted) as I think various labs rely on it includ= ing the github robot, loongson, Intel (Maybe, I don't know). UNH does n= ot use it much as we opt to meet the meson dependency=C2=A0separately in th= e dpdk-ci project's container template engine.

It will also require updates to the container=C2=A0template engine, which = I can get Cody started on tomorrow.
=C2=A0
Important note: if relevant to your CI, testing against LTS branches
must still be done with the 0.53.2 version, so no change relying on
post 0.53.2 meson feature gets backported.

<= div>Okay, full disclosure I don't think this is something we handled th= e last time the meson version got bumped in 2022. So, back then we just bum= ped the meson version for all environments to .53, then did LTS testing for= 19.11, 20.11, 21.11 from environments running meson .53. But, I understand= how this is an issue and something we should avoid this go around.=C2=A0

However, it is not ideal to set the meson version &= quot;at runtime" for CI testing based on the repo under test (mainline= and next-* want .57, old LTS versions want .53). It would be possible to m= odify our jenkinsfiles (automation scripts) to check the DPDK version, and = run pip commands resetting the meson version accordingly, at the start of e= ach testing job... but I have a couple concerns here with regards to stabil= ity/maintenance.=C2=A0

Another option, which Adam = is suggesting, is to create a dedicated environment which is version locked= to .53 (it can just be an ubuntu container image), label it as a meson .53= environment, and add that to the total list of dpdk build environments whi= ch are run when we do testing for either 22.11, or 23.11. Then, we could ru= n the rest of the testing from the same container images we use for mainlin= e (that have .57 baked in), and this would not be a problem because we woul= d have that 1 environment doing a dpdk build, which is guaranteed to be on = .53. Bruce/David let me know if you can think of any issues with this.=C2= =A0

This is also very similar to a Community Lab r= equest from a few months ago (which we have an open internal Jira ticket fo= r), which is to add a VM environment which is locked to the minimum support= ed kernel version for DPDK. But, that's another story...

=
Anyways, in terms of the timeline... the Jenkins script updates = are probably the most difficult in that they will require a PR review, dry = run tests etc. but it's still fairly trivial. Cody can probably update = the meson dependencies on the template engine and submit that to the dpdk-c= i project by end of week. So, I would say CI should be ready by next Tuesda= y, provided the patches which will be incoming to dev and ci mailing lists = can be merged. Is this timeline okay?
=C2=A0
--000000000000249a3f0623fc73e3--