From: Christian Melki <christian.melki@t2data.com>
To: Michael Olbrich <m.olbrich@pengutronix.de>
Cc: ptxdist@pengutronix.de
Subject: Re: [ptxdist] Patch series for package per project?
Date: Fri, 4 Mar 2022 09:24:51 +0100 [thread overview]
Message-ID: <7105cf63-9ef6-7c5a-594f-731cb92061cf@t2data.com> (raw)
In-Reply-To: <YiHJdIJPKEQ4cGwk@pengutronix.de>
On 3/4/22 9:10 AM, Michael Olbrich wrote:
> Hi,
>
> On Thu, Mar 03, 2022 at 09:35:36PM +0100, Alexander Dahl wrote:
>> On Thu, Mar 03, 2022 at 09:11:39PM +0100, Alexander Dahl wrote:
>>> On Thu, Mar 03, 2022 at 08:37:45PM +0100, Christian Melki wrote:
>>>> On 3/3/22 18:07, Felix Mellmann wrote:
>>>>> On 03.03.22 15:22, Christian Melki wrote:
>>>>>> Just one barebox version, but for different archs, with different
>>>>>> patchsets. I'd like the patches to live in the same place as they've
>>>>>> always done, i.e. under patches/package/...
>>>>>> But patches/package/series.$platform or similar does not seem to work?
>>>>>>
>>>>> Would it be an option to put the patches below each of the platformdirs?
>>>>>
>>>>> I ran into a similiar situation when starting to migrate to a different
>>>>> CPU platform. After a couple of years putting serveral "platformconfig"
>>>>> files within the same directory as "ptxconfig" I'm now using separate
>>>>> subdirs for each platform where separate sets of platform dependent
>>>>> patches are lying.
>
> That would be my first suggestion as well.
>
>>>> Ideally not. It irks me a bit that patches have to go to a different
>>>> place because they belong to another platform than the "default". Or
>>>> that they have to go somewhere else altogether because they need to be
>>>> split into platforms.
>>>> It doesn't make much sense to me.
>
> I guess that's a matter of perspective. For me, either the patch stack is
> shared. Then I out it in the common directory. Or each platform has a
> completely separate patch stack. Then it feels natural to have them in
> separate locations in each platform.
>
It is a matter of perspective and taste.
I prefer patches not scattered everywhere.
Ideally a structure at one point in a tree.
I don't like chasing:
"Where did this come from? Oh. Someone placed something somewhere else
too.", as in other unnamed environments.
>>> If I understand you correctly, your folder patches/barebox-2022.03.0
>>> (or whatever common version you use) must look like this somehow, all
>>> patches of the different series interleaved?
>>>
>>> 0001-apples.patch
>>> 0001-foo.patch
>>> 0001-this.patch
>>> 0002-bar.patch
>>> 0002-oranges.patch
>>> 0002-that.patch
>>> 0003-baz.patch
>>> series.one
>>> series.three
>>> series.two
>>
>> Now, what if those series are not mutually exclusive, but certain
>> patches are part of multiple series? Even worse: in different places,
>> like first patch in one, and third patch in the other series? Each
>> call of `git ptx-patches` would change the file numbers in the file
>> names, breaking the other series?
>
> Exactly. Maintaining shared patches is a mess. When I have more patches and
> especially if they are shared, then I work with a clone of the package
> upstream git. I use 'ptxdist local-src' for development and then export a
> full patch stack into the BSP.
> If the patch stacks for multiple platforms share some patches then they are
> in a shared branch in git, but in the BSP each platform has its own copy.
>
>
>>> Seriously, that looks messy to me, how should anyone looking at the
>>> directory know which patch belongs to which series without looking at
>>> the series files? What if someone wants to copy/move all patches
>>> belonging to only one series to a different place?
>>
Preferably not dumped like that no.
If I could, a directory structure would be nice.
>> What I would do, and in fact I did this with patches for U-Boot for
>> five different boards: throw all patches into one series. Why
>> separate them? Or if that's not possible, put distinct patch series
>> configs/platform-XXX/patches/barebox-2022.03.0 as suggested before.
>
> I personally don't like having unrelated and unnecessary patches in my
> patchstack...
>
>> Well, there's one more possibility: put the patch series to different
>> top layers. ;-)
>
> You could also put something like this in platforms/barebox-series.in:
>
> config BAREBOX_SERIES
> string
> default "series${PTXDIST_PLATFORMSUFFIX}"
> > This will be used automatically and you have a series for each platform.
> Or add a prompt and explicitly set the series filename.
>
Sure. I could copy the kernel handling.
But I'd prefer if that also could go away for a more generic handling.
Ie, kernel has this. If I give barebox this, it would be just cluttering.
Regards,
Christian
> Michael
>
_______________________________________________
ptxdist mailing list
ptxdist@pengutronix.de
To unsubscribe, send a mail with subject "unsubscribe" to ptxdist-request@pengutronix.de
next prev parent reply other threads:[~2022-03-04 8:26 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-03 9:17 Christian Melki
2022-03-03 13:40 ` Michael Olbrich
2022-03-03 14:22 ` Christian Melki
2022-03-03 17:07 ` Felix Mellmann
2022-03-03 19:37 ` Christian Melki
2022-03-03 20:11 ` Alexander Dahl
2022-03-03 20:35 ` Alexander Dahl
2022-03-04 8:10 ` Michael Olbrich
2022-03-04 8:24 ` Christian Melki [this message]
2022-03-04 15:16 ` Christian Melki
2022-03-04 15:34 ` Michael Olbrich
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=7105cf63-9ef6-7c5a-594f-731cb92061cf@t2data.com \
--to=christian.melki@t2data.com \
--cc=m.olbrich@pengutronix.de \
--cc=ptxdist@pengutronix.de \
/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