FWIW, I'd like to tighten the check for Pending, so that it would require a [reason] too. For existing pending patches it can simply say [legacy patch needing triage], but having to think of a reason will hopefully deter people from adding more Pending patches without at least pausing to think what they want to do with them (and ideally sending them upstream there and then).
Alex On Fri, 12 Jul 2024 at 11:52, Martin Jansa <martin.ja...@gmail.com> wrote: > > Agreed with what was said before about usefulness of Upstream-Status > (even if you don't see it at first). > > Instead of just disabling this QA check I would recommend to keep it > enabled and add at least Pending everywhere. > > Pending isn't very useful by itself, but at least it will mark the > .patch files where Upstream-Status wasn't decided yet (and where the > decision might be complicated if the .patch is very old added by > someone else etc.) while more importantly preventing new .patch files > being introduced without any Upstream-Status at all (and that's the > best time to catch this and the author should decide what > Upstream-Status should be). > > You don't need to run to build to find all the .patch files which > should be updated, there is very useful script to do that for you, > see: > openembedded-core/scripts/contrib/patchreview.py > > I did this for many layers with simple one line script (mentioned in > https://lists.openembedded.org/g/openembedded-core/message/197115) and > then incrementally worked on updating the Pending .patch files. > > Adding that to all the .patch files takes less time than this e-mail > thread did :). > > Regards, > > On Fri, Jul 12, 2024 at 11:32 AM Quentin Schulz via > lists.yoctoproject.org > <quentin.schulz=cherry...@lists.yoctoproject.org> wrote: > > > > 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 (#63479): https://lists.yoctoproject.org/g/yocto/message/63479 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] -=-=-=-=-=-=-=-=-=-=-=-
