All of lore.kernel.org
 help / color / mirror / Atom feed
From: Trevor Gamblin <tgamblin@baylibre.com>
To: Alexander Kanavin <alex.kanavin@gmail.com>,
	Frederic Martinsons <frederic.martinsons@gmail.com>
Cc: openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] Contributing, how it works?
Date: Fri, 5 May 2023 14:21:05 -0400	[thread overview]
Message-ID: <ce83564a-1362-f45d-8c4d-e33e68a72d27@baylibre.com> (raw)
In-Reply-To: <CANNYZj-q+5jxDxWDp_4B2kD4NVqWA-Fok2wuTUiLzzsO_5iYYw@mail.gmail.com>


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, 
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
> <frederic.martinsons@gmail.com> 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/7611679
>> Group Owner: openembedded-core+owner@lists.openembedded.org
>> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [tgamblin@baylibre.com]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>


  reply	other threads:[~2023-05-05 18:21 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-05 17:17 Contributing, how it works? Frédéric Martinsons
2023-05-05 17:37 ` [OE-core] " Alexander Kanavin
2023-05-05 18:21   ` Trevor Gamblin [this message]
2023-05-05 18:31     ` Frédéric Martinsons
2023-05-05 19:08       ` Trevor Gamblin
2023-05-05 19:26         ` Frédéric Martinsons
2023-05-05 18:26   ` Frédéric Martinsons
2023-05-05 19:05     ` Alexander Kanavin
2023-05-05 19:24       ` Frédéric Martinsons
2023-05-05 19:21 ` Michael Opdenacker
2023-05-05 19:32   ` Frédéric Martinsons

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=ce83564a-1362-f45d-8c4d-e33e68a72d27@baylibre.com \
    --to=tgamblin@baylibre.com \
    --cc=alex.kanavin@gmail.com \
    --cc=frederic.martinsons@gmail.com \
    --cc=openembedded-core@lists.openembedded.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.