Re: Adding Series Dependency to Patchwork

[Adam Hassick <ahassick@iol.unh.edu>]

On Tue, Jul 23, 2024 at 12:08 PM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
>
> On 7/23/2024 4:36 PM, Patrick Robb wrote:
> > On Tue, Jul 23, 2024 at 11:31 AM Ferruh Yigit <ferruh.yigit@amd.com> wrote:
> >>
> >> On 7/22/2024 5:28 PM, Patrick Robb wrote:
> >>> On Mon, Jul 22, 2024 at 12:15 PM Adam Hassick <ahassick@iol.unh.edu> wrote:
> >>>
> >>>>> If we go with the URL option, does is still required to differentiate as
> >>>>> "patch-xxx" or "series-yyy", previously they were different IDs, but
> >>>>> 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 figure
> >>>> out whether it points at a patch or a series. No need to differentiate
> >>>> 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: <message-ID>
> >> or
> >> Depends-on: <patchwork URL>
> >>
> >
> > 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: <patchwork URL>
> >>
> >
> > 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.