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 96475456A2; Wed, 24 Jul 2024 17:06:08 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 913EE42DA3; Wed, 24 Jul 2024 17:06:08 +0200 (CEST) Received: from mail-yb1-f169.google.com (mail-yb1-f169.google.com [209.85.219.169]) by mails.dpdk.org (Postfix) with ESMTP id DFF3D43496 for ; Wed, 24 Jul 2024 17:06:06 +0200 (CEST) Received: by mail-yb1-f169.google.com with SMTP id 3f1490d57ef6-e0b167da277so565803276.3 for ; Wed, 24 Jul 2024 08:06:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iol.unh.edu; s=unh-iol; t=1721833566; x=1722438366; darn=dpdk.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=PBAMOMPzE2Dv03cL9Wp0qw410RMAc6heJMOhGqLffwY=; b=TBDHJJ9gxmyGX0ruEXyFKBuy69b4rb5+6glNrkNy+sPTumJM9HsyGS+uK2mcqhVYpp lhQs1p+WeZJo6/Ct9KUhYLN/NWd7nj2y6RnVP2hLAiK4drvslhWLrjaLSyzWmf4dYcwn /Xtkcso+rpUKElZTTR8VgvIYjhqbljTWiblDM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721833566; x=1722438366; h=content-transfer-encoding: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=PBAMOMPzE2Dv03cL9Wp0qw410RMAc6heJMOhGqLffwY=; b=FRsoc5ns21PCeqTn5XreqxxeTqU1bhNNaZ8z0hW7GFAltcj1Xu1oyR10jiXsDM4hcn iYwxg1/YwdxRFwt2+5eYe1j6QnXBgAPcO7t7zy6LIzElytkpEmFzZnPGpTHpw6zDhS7k RBGJ0egxE+QTp4q7ek1wprzUmiON9uWvB0IWE9cNZopbM9eLg9afwnsotG7WE4K1eIH+ AUR6CNOoeEtcwSU70Gk3vstDrUWFKQgC/FDrf1GxOS4rwngxMXov5EJrMFpy5oU0pr14 JU2q14Mc75CXaVEjiI7OVCXKYBl9EL0JVwYbT9LMO8szrJBaEDkg0GujCCpsirNwE8Nb 7elg== X-Forwarded-Encrypted: i=1; AJvYcCXtvJaJyfqes2bULd7UP+AHp8g/NQm0/ELNy9lyHWj6jR53zpybQrpVQ9E7C5CQ7xDfJ87c2nGUN+U4fg== X-Gm-Message-State: AOJu0YyrpdPFMD+i0n1UldikvAksqDnhBWzonWOcFQ1cJhYTAnktgKTp mencxr9xItn0rq14E6Hle6L7LKlmlJiRq3YGqzqLyjMZC5A0QTBHnR/FbgFg0HTXiUj5yD3maME jYWEKpmgUZiptYTGuT7EriwUhTfOlQgC5BfPcQSvSHd7DW5jSlwxvbQ== X-Google-Smtp-Source: AGHT+IFAu5gxxwJJJdBZxlVJVkm5euWSQuTVKMTDSx15CwXh7Iz4npYq+JsVFWWqSBr/qY5B17wcuD+ZzesW4TbfQkI= X-Received: by 2002:a05:690c:86:b0:61b:df5:7876 with SMTP id 00721157ae682-671f07f36ecmr34257127b3.6.1721833565972; Wed, 24 Jul 2024 08:06:05 -0700 (PDT) MIME-Version: 1.0 References: <4881077.GXAFRqVoOG@thomas> <76332523-96ac-407d-b937-c1f8a99808fa@amd.com> <6b425d90-78b2-497b-958c-9d36e2ba6e3b@amd.com> <9f800999-98b1-4e18-bd14-352affb81da6@amd.com> In-Reply-To: <9f800999-98b1-4e18-bd14-352affb81da6@amd.com> From: Adam Hassick Date: Wed, 24 Jul 2024 11:07:06 -0400 Message-ID: Subject: Re: Adding Series Dependency to Patchwork To: Ferruh Yigit Cc: Patrick Robb , ci@dpdk.org, Aaron Conole Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 On Tue, Jul 23, 2024 at 12:08=E2=80=AFPM Ferruh Yigit wrote: > > On 7/23/2024 4:36 PM, Patrick Robb wrote: > > On Tue, Jul 23, 2024 at 11:31=E2=80=AFAM Ferruh Yigit wrote: > >> > >> On 7/22/2024 5:28 PM, Patrick Robb wrote: > >>> On Mon, Jul 22, 2024 at 12:15=E2=80=AFPM Adam Hassick wrote: > >>> > >>>>> If we go with the URL option, does is still required to differentia= te as > >>>>> "patch-xxx" or "series-yyy", previously they were different IDs, bu= t > >>>>> with URL can patchwork deduce if it is series or patch? If so this = can > >>>>> bring a simplification. > >>>> > >>>> No, you can just paste the URL and the Django URL resolver will figu= re > >>>> out whether it points at a patch or a series. No need to differentia= te > >>>> with the URLs. > >>>> > >>>> That's also true of the message ID option too. There isn't much of a > >>>> point in differentiating patch/series message IDs because series do > >>>> not reliably have an email associated with them. > >>> > >>> Sounds good. I want to highlight again for the ci group that all > >>> dependencies will be series dependencies, regardless of whether > >>> "patch-xxx" or "series-yyy" is used. If a patch message id or url is > >>> submitted, it will be mapped to its series url for the dependency. > >>> > >> > >> Are you planning to keep the 'patch' or 'series' part, why not change > >> the syntax as: > >> > >> Depends-on: > >> or > >> Depends-on: > >> > > > > Good point. Yes, there is no reason to keep the "patch" or "series" > > prefix to the value. > > > >> > >> And is there a benefit to support both "message-ID" and "patchwork URL= ", > >> so why not just: > >> Depends-on: > >> > > > > Maybe Adam can answer, but I think his intention was to support both > > formats, to provide more flexibility for users. > > > > I am not sure if this flexibility is required, I am feeling it can be > simpler to support one. > And parser can convert form one to another if it is required at some > point by the tool. There seems to be some interest in providing multiple types of IDs on the Patchwork end. Supporting a URL is convenient and supporting a message ID provides a use case that better aligns with the Patchwork design principle of not polluting changelogs with Patchwork related metadata (such as URLs). Also, other SCM tools like Gerrit and b4 use message ID to reference other patches. I had someone mention adding the "change-id" feature from b4/gerrit to reference patch series on the GitHub issue, so there may be interest in adding more accepted value types to Depends-on in the future. If simplicity for our developers is the concern, then we could only mention one of these methods in our documentation. An unrelated note about the v2: Earlier I mentioned that we might support cover letter IDs to reference a series dependency. I've decided to forgo that feature because developers do not always resubmit cover letters when they submit new versions of a patch series. For example, if they depend on the v3 of a patch and they use the cover letter message ID submitted with v1, that will introduce a dependency on v1. This could lead to some confusion.