Le ven. 5 mai 2023, 19:37, Alexander Kanavin <alex.kana...@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.martins...@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 (#180966): https://lists.openembedded.org/g/openembedded-core/message/180966 Mute This Topic: https://lists.openembedded.org/mt/98710419/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
