Hi Yann,
On 7/11/24 3:50 PM, Yann CARDAILLAC via lists.yoctoproject.org wrote:
You don't often get email from ycnakajsph=gmail....@lists.yoctoproject.org. Learn why
this is important<https://aka.ms/LearnAboutSenderIdentification>
Well, I'm not really sure I would need it in most cases.
For instance today I was modifying an existing device tree to make it fit my
board, that's not necessarily going to last.
I assume it'll make it to your upstream repo which contains this device
tree, so there'll be no patch in Yocto after your debugging session ends.
Or say I have a package, which is from my company and doesn't have any reason
to get out of it.
If it's from your company, you own the repo where the source code is
stored, so fix the source code in the repo once you're done with the
debugging session.
As an integrator I need to modify the build system, let's say something in the
makefile, or maybe there's simply stuff that I don't want on my system.
If it is source code from your company, then fix it in the repo. If it's
from a third party that isn't public, send them the patch so you
eventually don't have to maintain this on your own, if it's public and
open-source code, contribute back so you don't have to maintain this
patch once you upgrade to a new version of the package (as part of a
full Yocto upgrade or not).
So I'll make a patch.
Why would Yocto be authority for the way my commits are formatted? In all the
above cases I don't see why.
You can disable the warning, we're just strongly recommending you to
follow the format we came up with. Why? Because we've had years/decades
of experience with handling patches we only had in layers. We went
through the pain (and still go) of finding out if the patch is
necessary, if it was sent upstream, if so, should we rework it based on
newer versions of that patch, was it merged upstream, if so in which
form and when, was it rejected, if so, why, security issue, broken
logic, etc...
Where and how was the patch submitted etc. It also encourages us to
contribute upstream, which means they then know the build system(s)
compiling the source code and their usecases so they have it in mind for
future development.
Yocto/OE needs to be opinionated (it factually cannot, because not
implementing something like this if it's suggested means we have the
opinion it's not necessary), but for most parts, it's still very very
flexible, so feel free to disable the check we put in place to prevent
people shooting their own foot :)
Cheers,
Quentin
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#63477): https://lists.yoctoproject.org/g/yocto/message/63477
Mute This Topic: https://lists.yoctoproject.org/mt/107142644/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
