[Toaster] The Toaster process overview - 10 steps to enlightenment

[Paul Eggleton]

Hi David,

Thanks for putting this together. Some comments inline.

On Friday 17 January 2014 07:23:01 Reyna, David wrote:
> ========================
> 
> [[ Set up the local repository ]]
> 
> 
> (1) Select a Yocto-1.5 compatible host, and install Django-1.5. The "pip"
> application is recommended to manage the install process.
> 
>    https://www.djangoproject.com/download/
> 
>   $ sudo apt-get install pip
>   $ sudo pip uninstall django
>   $ sudo pip install django==1.5
> 
> 
> (2) Setup a local repository for the development branch
> 
>   $ cd <installdir>
>   $ git clone git://git.yoctoproject.org/poky
>   $ cd poky
>   $ git remote add contrib http://git.yoctoproject.org/git/poky-contrib
>   $ git fetch contrib
>   $ git checkout contrib/toaster/master -b toaster-master
> 
> # Also, setup up your branch for pushes to Yocto poky-contrib
> 
>   $ git remote set-url contrib git at git.yoctoproject.org:poky-contrib
> 
> 
> [[ Set up the project and Toaster interface ]]
> 
> 
> (3) Create a project, with toaster database capture enabled
> 
>   $ cd <installdir>
>   $ source poky/oe-init-build-env
>   $ source toaster start
>   $ bitbake core-image-minimal
> 
> # NOTE: the Toaster MUST be started before the project's build, else
> # no data will be captured. You can recover a working (if sparse)
> # database if you do this to execute a quick re-build.
> 
>   $ source toaster start
>   $ bitbake -c cleansstate base-files
>   $ bitbake core-image-minimal
> 
> 
> (4) Run the toaster interface
> 
>   $ xdg-open http://localhost:8000/
> 
> # NOTE: You can alternatively open your browser manually to:
> 
>   http://localhost:8000/
> 
> 
> [[ Edit and submit content for review ]]
> 
> 
> (5) Create a local branch
> 
> # NOTE: the branch name is generally of the form
> "<username>/<a_name_for_the_branch>", # for example
> "dreyna/recipe-detail-view". You can choose any user name and send it # to
> Michael Halstead <mhalstead at linuxfoundation.org> together with your SSL
> public key # to enable your pushes to "poky-contrib".
> 
> Example:
>   $ BRANCH_NAME="dreyna/recipe-detail-view"
>   $ git checkout -b $BRANCH_NAME
> 
> 
> (6) Edit and test your content.
> 
> # NOTE: All rendered pages should be validated for HTML format compliance.
> # Here are some suggested HTML validators:
>   * Firebug (https://getfirebug.com/)
>   * HtmlValidator (http://users.skynet.be/mgueury/mozilla/)
> 
> 
> (7) Set up your commit(s). The same push can have several partitioned
> commits.
> 
>   $ cd <installdir>/poky
>   $ git add bitbake/lib/toaster/...
>   $ git commit

The last should be "git commit -s" - then you don't need to add the Signed-off-
by manually.
 

> # NOTE: The format of the commit should be as the following:
> 
> vvvvvvvvvvvvvvvvvvvvvvvvv
> <short one line summary>
> 
> [YOCTO #0000]          # OPTIONAL LINE: replace with the real bugzilla issue
> number
> 
> <long(er) description, can be multi-line, should break at around 60 chars>
>
> Signed-off-by: First Last <name at company.com>
> ^^^^^^^^^^^^^^^^^^^^^^^^^

FYI we have a comprehensive document about commit messages here, which we 
should probably link to:

http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines


> (8) Push your branch for review
> 
>   $ git push contrib $BRANCH_NAME
> 
> See it on the web using the branch name, for example:
> 
>  
> http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/?h=dreyna%2Frecipe-d
> etail-view

I'd suggest in our example we not use a variable here for the branch name, 
because if the variable becomes unset (such as in a new session) you'll be 
pushing the default branch which could potentially be a bad thing. Obviously 
on your own machine you're free to do as you wish ;)


> (9) Send an email to "toaster at yoctoproject.org" with the following content.
> 
>   (a) A brief description of the review request together with the branch
> name
> 
>   (b) Any technical details to call out to reviewers
> 
>   (c) Any limitations, assumptions, dependencies, and/or differed work
> 
>   (d) A test plan that demonstrates how the feature was tested
>       with sufficient detail for general testers and
>       documentation writers.

FWIW, we're not as strict about (d) in the rest of the project. Can't hurt 
though :)


> [[ Rebase your repository from master ]]
> 
> 
> (10) To update your repository to the latest content, rebase it (as
> opposed to attempted a merge).
> 
>   $ cd <installdir>/poky
>   $ git fetch
>   $ git rebase [-i] poky-contrib

The argument to rebase is a ref (branch name, tag name, hash, etc.), so a 
better example here would be contrib/toaster/master, assuming the poky-contrib 
remote is called contrib as you've written above.

Cheers,
Paul
---------------------------------------------------------------------
Intel Corporation (UK) Limited
Registered No. 1134945 (England)
Registered Office: Pipers Way, Swindon SN3 1RJ
VAT No: 860 2173 47

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.