Contributing, how it works?

Contributing, how it works?

[Frédéric Martinsons]

[-- Attachment #1: Type: text/plain, Size: 1594 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 2027 bytes --]

Re: [OE-core] Contributing, how it works?

[Alexander Kanavin]

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
<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 (#180960): https://lists.openembedded.org/g/openembedded-core/message/180960
> Mute This Topic: https://lists.openembedded.org/mt/98710419/1686489
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [alex.kanavin@gmail.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

Re: [OE-core] Contributing, how it works?

[Trevor Gamblin]

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]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>

Re: [OE-core] Contributing, how it works?

[Frédéric Martinsons]

[-- Attachment #1: Type: text/plain, Size: 5833 bytes --]

Le ven. 5 mai 2023, 19:37, Alexander Kanavin <alex.kanavin@gmail.com> a
écrit :

> There is
> http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded


I do know this one.

>
> and some additional pages linked from it:
> http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines
> http://www.openembedded.org/wiki/Styleguide


I didn't know about these two links, thanks Alexander (and I'll slap myself
for not following the links from the first page you mentioned)


>
> 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?


Of course it is. I even do a clean of shared state before that, just to be
sure (shared state had often caused me trouble in the past).

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.


That's what I did for unit test of rust recipes and I didn't get much
comments beside you and khem 15 days ago. And I still don't know if my
patches are an issue or if nobody had the time to look at them, it's pretty
frustrating.

By the way, the statement "just write some code and publish on the list for
comments" can be a blocker for a newcomer which don't know about the rules.
During my career, I often saw people too shy to contribute because they
thought they didn't meet the requirements.

 I'm sure everyone here is willing to help newcomers but having a clear
entry point (a front web page on oe/yocto site on how to make a good
contribution and clear guidelines to follow ) can be a relief for shy
people.

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 :)
>

I would like to know about these, I hear a lot in this list about
autobuilder and it seems close to what I know of continuous integration
(some build of multiple configuration with the submitted patch and tests
towards that) but I don't know how to replicate the config of those locally
on my machine (in case of errors), do you have any links for that?

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
>

Ah great, if you point me to where I can find insights about this patchset
test framework, I would gladly offer my help to fox the issue. From what
you are saying, I understand that fixing this will make the contribution
smoothier.


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 (#180960):
> https://lists.openembedded.org/g/openembedded-core/message/180960
> > Mute This Topic: https://lists.openembedded.org/mt/98710419/1686489
> > Group Owner: openembedded-core+owner@lists.openembedded.org
> > Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> alex.kanavin@gmail.com]
> > -=-=-=-=-=-=-=-=-=-=-=-
> >
>

[-- Attachment #2: Type: text/html, Size: 9006 bytes --]

Re: [OE-core] Contributing, how it works?

[Frédéric Martinsons]

[-- Attachment #1: Type: text/plain, Size: 5161 bytes --]

Le ven. 5 mai 2023, 20:21, Trevor Gamblin <tgamblin@baylibre.com> 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?


> 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]
> >> -=-=-=-=-=-=-=-=-=-=-=-
> >>
>

[-- Attachment #2: Type: text/html, Size: 7297 bytes --]

Re: [OE-core] Contributing, how it works?

[Alexander Kanavin]

On Fri, 5 May 2023 at 20:26, Frédéric Martinsons
<frederic.martinsons@gmail.com> wrote:
> That's what I did for unit test of rust recipes and I didn't get much comments beside you and khem 15 days ago. And I still don't know if my patches are an issue or if nobody had the time to look at them, it's pretty frustrating.

They've been merged to master I think? Can you check that by
fetch/rebase? Yes, there is no separate notice when it happens, and
it's frustrating to first time contributors, but again, someone needs
to sit down and write an email bot to do the job.

> I would like to know about these, I hear a lot in this list about autobuilder and it seems close to what I know of continuous integration (some build of multiple configuration with the submitted patch and tests towards that) but I don't know how to replicate the config of those locally on my machine (in case of errors), do you have any links for that?
>

You probably should to start with reading
https://docs.yoctoproject.org/test-manual/index.html ?

> Ah great, if you point me to where I can find insights about this patchset test framework, I would gladly offer my help to fox the issue. From what you are saying, I understand that fixing this will make the contribution smoothier.

That you should discuss with Trevor.

Alex

Re: [OE-core] Contributing, how it works?

[Trevor Gamblin]

[-- Attachment #1: Type: text/plain, Size: 6182 bytes --]


On 2023-05-05 14:31, Frédéric Martinsons wrote:
>
>
> Le ven. 5 mai 2023, 20:21, Trevor Gamblin <tgamblin@baylibre.com> 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

- 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
>     > <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
>     <mailto:openembedded-core%2Bowner@lists.openembedded.org>
>     >> Unsubscribe:
>     https://lists.openembedded.org/g/openembedded-core/unsub
>     [tgamblin@baylibre.com]
>     >> -=-=-=-=-=-=-=-=-=-=-=-
>     >>
>

[-- Attachment #2: Type: text/html, Size: 11634 bytes --]

Re: [OE-core] Contributing, how it works?

[Michael Opdenacker]

Hi Frederic

On 05.05.23 at 19:17, Frederic Martinsons 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".


Thanks for starting this thread! We precisely have plans to consolidate 
docs on how to contribute.

See   https://www.openembedded.org/wiki/Document_Consolidation and 
https://wiki.yoctoproject.org/wiki/Maintainers_Manual for a list of 
documents we want to consolidate.

Cheers
Michael.

-- 
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [OE-core] Contributing, how it works?

[Frédéric Martinsons]

[-- Attachment #1: Type: text/plain, Size: 1821 bytes --]

On Fri, 5 May 2023 at 21:05, Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> On Fri, 5 May 2023 at 20:26, Frédéric Martinsons
> <frederic.martinsons@gmail.com> wrote:
> > That's what I did for unit test of rust recipes and I didn't get much
> comments beside you and khem 15 days ago. And I still don't know if my
> patches are an issue or if nobody had the time to look at them, it's pretty
> frustrating.
>
> They've been merged to master I think? Can you check that by
> fetch/rebase? Yes, there is no separate notice when it happens, and
> it's frustrating to first time contributors, but again, someone needs
> to sit down and write an email bot to do the job.
>

yes, after re-checking, my commits have been merged this morning. I would
like to know more about "write an email bot to do the job" because
having a submission accepted by maintainers and merged is some kind of
"reward" (the only one when we are a fresh submitter to the project).
And having a reward is motivating to contribute more.

> I would like to know about these, I hear a lot in this list about
> autobuilder and it seems close to what I know of continuous integration
> (some build of multiple configuration with the submitted patch and tests
> towards that) but I don't know how to replicate the config of those locally
> on my machine (in case of errors), do you have any links for that?
> >
>
> You probably should to start with reading
> https://docs.yoctoproject.org/test-manual/index.html ?
>
> > Ah great, if you point me to where I can find insights about this
> patchset test framework, I would gladly offer my help to fox the issue.
> From what you are saying, I understand that fixing this will make the
> contribution smoothier.
>
> That you should discuss with Trevor.
>
> Alex
>

[-- Attachment #2: Type: text/html, Size: 2555 bytes --]

Re: [OE-core] Contributing, how it works?

[Frédéric Martinsons]

[-- Attachment #1: Type: text/plain, Size: 6030 bytes --]

On Fri, 5 May 2023 at 21:08, Trevor Gamblin <tgamblin@baylibre.com> wrote:

>
> On 2023-05-05 14:31, Frédéric Martinsons wrote:
>
>
>
> Le ven. 5 mai 2023, 20:21, Trevor Gamblin <tgamblin@baylibre.com> 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
>> > <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]
>> >> -=-=-=-=-=-=-=-=-=-=-=-
>> >>
>>
>

[-- Attachment #2: Type: text/html, Size: 11223 bytes --]

Re: [OE-core] Contributing, how it works?

[Frédéric Martinsons]

[-- Attachment #1: Type: text/plain, Size: 2922 bytes --]

On Fri, 5 May 2023 at 21:21, Michael Opdenacker <
michael.opdenacker@bootlin.com> wrote:

> Hi Frederic
>
> On 05.05.23 at 19:17, Frederic Martinsons 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".
>
>
> Thanks for starting this thread! We precisely have plans to consolidate
> docs on how to contribute.
>
> See   https://www.openembedded.org/wiki/Document_Consolidation and
> https://wiki.yoctoproject.org/wiki/Maintainers_Manual for a list of
> documents we want to consolidate.
>
> Cheers
> Michael.
>
> --
> Michael Opdenacker, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com


Oh great ! thank you Michael, be sure I will read those links.
And thanks everyone for giving all these documents, I'll have a busy
weekend to look at them all.

 Again, I think having a focus point which gathers all these docs would be
a great help but maybe
the link you gave Michael will be a starting point.

By the way, I'm starting to think that I should write an article (blog
post, tweet, whatever ...) about
my journey about yocto/oe contributions, it may help future contributors.

 But since I never write a publicly available article, it may
not be in the coming weeks.... (and I should improve my skills in writing
before going there)

[-- Attachment #2: Type: text/html, Size: 3988 bytes --]