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.

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 (#180962): 
https://lists.openembedded.org/g/openembedded-core/message/180962
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]]
-=-=-=-=-=-=-=-=-=-=-=-

Reply via email to