New Dev

From Openembedded.org

This page is really nothing more than a work-in-progress right now. Eventually, it would be nice to have this page to show to every contributor who just got his RW access.

Contents 1 Prologue 2 steps to gain commit access to OpenEmbedded 3 Welcome Message 4 common mistakes

Prologue

Things you should do and know about

• read the oe-devel and oe-commits mailing list
• Our policies which tell you for example how to create a proper commit
• learn about the cool things you can do with git and bitbake
• be careful before you commit anything (Todo: document in this wiki the points raised by RP and koen) and respect the review process
• Patchwork - our tool to review patches sent to the mailing lists
• our bug tracker

But most importantly: Have fun working in OE and with others from the community. Things may be daunting, but help is always available to you in the mailing list and IRC.

steps to gain commit access to OpenEmbedded

1. Supply patches to mailing list
2. Have someone propose commit access for you
3. Get two developer votes in favour of your request
4. Send your SSH key to Mickey

Welcome Message

Hi,

If you are reading this, you have been granted commit access to the award winning OpenEmbedded Project. 
To make things go smoothly we have some basic rules:

 1) Everything outside org.openembedded.dev/recipes/ should be treated with extreme care. 
    Please communicate with other developers first if you want to touch that area. 

    If you are a distro maintainer you are of course free to touch your distro config files without asking. 
    If you are a machine maintainer, please communicate first, 
    since it's easy to get things wrong and not all machines are good examples to copy from.

 2) Think twice before using an override, usually overrides can be avoided, especially ones like these:

     do_compile() {
         oe_runmake 
     }  

     do_compile_myfirstdisto() {
         oe_runmake -D_GNU_SOURCE
     }
    
    You may think "I don't want to break other distributions", but in 99% of the cases your fix will unbreak other distros as well, 
    so using an override will cause more work for other developers, since they have to work out the fix by themselves. 
    You don't want other people to spend weeks trying to solve a problem which solution is masked by a bogus override.

 3) It's fine to fix a recipe you don't maintain, but if you are unsure of your change, try to contact the maintainer or, 
    if no maintainer is listed, send a note to the OE developer mailinglist. 

 4) Split your changes into their logical subparts. It's easier to track down problems afterwards with a binary search.

 5) Have a clear commit messages, and mention the affected bugnumbers if appropriate.

 6) Sync early, sync often. Nobody likes to reinvent the wheel. Branching and merging is easy with git, 
    so don't hesitate to run sync just before your plane takes off and your wifi gets disconnected.

You can view our policies and cheatsheets at:
 
 * http://wiki.openembedded.net/index.php/Policies
 * http://wiki.openembedded.net/index.php/Git
 * http://wiki.openembedded.net/index.php/GitPhraseBook

common mistakes

• If your commit changes contents of packages you **need** to bump PR