On Fri, 5 May 2023 at 21:08, Trevor Gamblin <[email protected]> wrote:
> > On 2023-05-05 14:31, Frédéric Martinsons wrote: > > > > Le ven. 5 mai 2023, 20:21, Trevor Gamblin <[email protected]> a > écrit : > >> >> On 2023-05-05 13:37, Alexander Kanavin wrote: >> > There is >> > http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded >> > and some additional pages linked from it: >> > http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines >> > http://www.openembedded.org/wiki/Styleguide >> > >> > The wiki is not great, and needs improvements, but the problem is it's >> > difficult to write an authoritative and comprehensive answer to the >> > questions you ask because there's just so many possible things one >> > could check with any change to yocto. If you touch a recipe, you >> > should of course check that 'bitbake recipe' still completes without >> > an error. But that's obvious, isn't it? Beyond that... it depends. And >> > requires a bit of intuition and experience, or advice from someone who >> > knows the specific item better. >> > >> > We generally don't expect people to learn 'the rules' upfront - just >> > write some code, and if you're not certain how to test it properly or >> > whether it even makes sense, submit the patch as RFC and ask to take a >> > look. If it fails in integration testing, you'll hear about it too, >> > and that's normal and expected for anything more complex than a typo >> > fix. My patches appear 'perfect' only because I pre-test them myself >> > on the autobuilder :) >> > >> > Where we would *greatly* appreciate help is a special bot called >> > patchtest that used to check mailing list submissions for common >> > problems. That fell into disrepair due to lack of maintenance. Fixing >> > that would be fantastic - and people could run it locally too. That >> > could act as both a repository of rules-as-code, and a way to check >> > them automatically. It could also offer hints for testing, depending >> > on what the change touches. All sorts of nice things, if there is a >> > person looking after it. >> >> I'm actually working on getting patchtest running again, and I've >> assigned myself as maintainer :) >> >> To add to what Alex said, a good place for you to start might be looking >> at the Newcomer Bugs list: >> https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs >> >> Alternatively, watching AUH failures and figuring out broken upgrades, > > > What is AUH? Where I can see broken upgrades you talked about? And more > important to me, how can I replicate them to investigate on my side? > > AUH is "Auto Upgrade Helper". If you search the OE-core mailing list for > the acronym, you will sometimes see results like this: > > [OE-core] [AUH] icu: upgrading to 73-1 FAILED > > These could be another area to look at contributing in addition to the > Newcomer Bugs or other parts of the Bugzilla, but the Newcomer list is > probably the best place to get yourself familiarized. > > You may find this page useful when it comes to recipe upgrades: > https://docs.yoctoproject.org/dev/dev-manual/upgrading-recipes.html > Alright, I will take a look. Thanks trevor. > - Trevor > > > >> or looking on the Bugzilla under terms like "ptest" could also be very >> useful, while providing better understanding of how recipes are written >> and being somewhat more accessible. >> >> You can also ask questions in the #yocto channel on the Libera.Chat IRC >> server if you need additional help. >> >> - Trevor >> >> > >> > Alex >> > >> > On Fri, 5 May 2023 at 19:17, Frederic Martinsons >> > <[email protected]> wrote: >> >> Hello list >> >> >> >> I'm wondering if there are documentations on how contribution are >> managed for the project. >> >> >> >> I try to find some but didn't manage to. There are easily reachable >> doc about how to contribute of course (how to make patches, fixe your >> identity, send mail via git... etc) but I didn't find what I usually find >> on other open source project (CONTRIBUTING.md file most of the time) like >> >> - what are the tests do should I run before submitting (I learnt by >> practice about test image or bitbake selftest for example) ? >> >> - is there a specific configuration that I should test before >> submitting (poky is ok, or should I also test another distro)? >> >> - does some commit writing rules exist ? (some projects want >> commits to begin with a prefix, usually the software component that is >> modified by the patch for example) >> >> - what are the coding rules you should follow, if any? (having >> common coding rules helps greatly the review of patches, pylint for python >> code for example, and I saw there are some bitbake recipes linter from >> meta-sca layer) >> >> >> >> Long story short, I really would like to know what are the different >> steps a patch should go through before being merged into master (and as a >> side question, what are the steps for a patch to be backported into one of >> the LTS branch). >> >> >> >> I'm deeply sorry if all these questions are obvious to you and have >> been already answered somewhere, in that case, please just give me the link. >> >> >> >> I recently started to contribute to yocto / oe and I think it will >> help me to make better contributions if I know more of how it works "under >> the hood". >> >> >> >> Best regards. >> >> >> >> >> >> >> >> >> >> >> >> >> >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#180976): https://lists.openembedded.org/g/openembedded-core/message/180976 Mute This Topic: https://lists.openembedded.org/mt/98710419/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
