Re: Adding Series Dependency to Patchwork

[Ferruh Yigit <ferruh.yigit@amd.com>]

On 7/24/2024 4:07 PM, Adam Hassick wrote:
> 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.
> 

If there are usecases to use both format, sure. And we can expose all to
users.


> 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.
>

As far as I can see if a patch series has cover letter, more likely it
will have cover letter in next version.

If cover letter is not supported, and dependent series has a cover
letter, is the expectation to add first patch of the series as
dependency skipping cover letter? This maybe also confusing.

For the sample you give, if dependent patch decided to drop cover letter
in v3, won't it work to provide first patch of v3 as dependency?