From: Ferruh Yigit <ferruh.yigit@amd.com>
To: Patrick Robb <probb@iol.unh.edu>
Cc: Adam Hassick <ahassick@iol.unh.edu>,
ci@dpdk.org, Aaron Conole <aconole@redhat.com>
Subject: Re: Adding Series Dependency to Patchwork
Date: Tue, 23 Jul 2024 17:08:26 +0100 [thread overview]
Message-ID: <9f800999-98b1-4e18-bd14-352affb81da6@amd.com> (raw)
In-Reply-To: <CAJvnSUB6MzBQ=bdzjZRYpwjt2nAewYvdptcpyy_u1k2K=sA-Zw@mail.gmail.com>
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.
next prev parent reply other threads:[~2024-07-23 16:08 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-22 19:51 Adam Hassick
2024-04-04 13:50 ` Patrick Robb
2024-04-05 6:41 ` Thomas Monjalon
2024-04-11 14:18 ` Aaron Conole
2024-04-11 14:33 ` Patrick Robb
2024-07-12 20:15 ` Adam Hassick
2024-07-19 15:32 ` Patrick Robb
2024-07-19 17:43 ` Ferruh Yigit
2024-07-19 17:40 ` Ferruh Yigit
2024-07-22 16:16 ` Adam Hassick
2024-07-22 16:28 ` Patrick Robb
2024-07-23 12:41 ` Aaron Conole
[not found] ` <6b425d90-78b2-497b-958c-9d36e2ba6e3b@amd.com>
2024-07-23 15:36 ` Patrick Robb
2024-07-23 16:08 ` Ferruh Yigit [this message]
2024-07-24 15:07 ` Adam Hassick
2024-07-25 9:47 ` Ferruh Yigit
2024-07-25 17:52 ` Patrick Robb
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9f800999-98b1-4e18-bd14-352affb81da6@amd.com \
--to=ferruh.yigit@amd.com \
--cc=aconole@redhat.com \
--cc=ahassick@iol.unh.edu \
--cc=ci@dpdk.org \
--cc=probb@iol.unh.edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).