Yocto Project - User contributions [en]

Contribute to Toaster

2016-01-18T15:42:38Z

Ed: /* Submitting patch sets for integration into Bitbake */

[[Category:Toaster]]
This page summarises the Toaster development process. We hope this will help you start contributing to the project.

== What can I do? ==

The [https://bugzilla.yoctoproject.org/buglist.cgi?product=Toaster Yocto Project Bugzilla instance] lists all the things that need to be done:

* If the issue says <strong>GUI design available</strong> in the Whiteboard field, there is a design specification document attached to the issue that you should follow. Send questions / comments about it to the [https://lists.yoctoproject.org/listinfo/toaster Toaster mailing list]
* If the issue says <strong>GUI design pending</strong> in the Whiteboard field, there is some design work still to be done. Feel free to take the issue and send an email to the [https://lists.yoctoproject.org/listinfo/toaster Toaster mailing list] to find out why the design work is not done yet

== Set up the local repository ==

For development of Toaster we recommend setting up a local install of Toaster. General install instructions are available in the main [https://www.yoctoproject.org/documentation/toaster-manual Toaster documentation]

Clone the poky repository
<code>
$ git clone git://git.yoctoproject.org/poky
$ cd poky
</code>

Install a python virtual environment to sandbox the python modules from your OS.
Enter Activate the python virtual environment in your current shell.
<code>
$ virtualenv venv
$ source ./venv/bin/activate
</code>

Install the python module dependencies for Toaster
<code>
$ pip install -r ./bitbake/toaster-requirements.txt
</code>

Run the setup and start script, follow instructions displayed
<code>
$ TOASTER_MANAGED=1 TOASTER_DEVEL=1 ./bitbake/bin/toaster
</code>

== Submitting patches ==

Publishing your patches to Toaster is a two step process.
# Sending patches to Toaster Project for review
# Submitting the patches that you reviewed to the upstream repository

Toaster code lives in Bitbake repository at [http://git.openembedded.org/bitbake/|http://git.openembedded.org/bitbake/].
All contributions must be upstreamed to the Bitbake repository in order to make it to the "master" branch of the poky/ repository.

=== Workflow ===
We are now supporting a [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/ poky-contrib] toaster-next branch. The purpose of this branch is to speed up our work so that we can base patches on top of patches that are waiting for upstream inclusion but have not yet made it into master. To facilitate this we have some extra rebasing actions needed.

1) Add poky-contrib to the local repository you set up above
<code> git remote add contrib git://git.yoctoproject.org/poky-contrib </code>

2) Start your feature branch off of toaster-next
<code> git checkout -b the/target/branch contrib/toaster-next </code>

3) Do Work

4) Rebase on toaster-next. It has probably changed while you were working (unless you are really really fast!)
<code> git rebase contrib/toaster-next </code>

5) Send to the toaster-mailing list using one of the methods outlined below.

=== Sending patches to Toaster Project ===

<strong>NOTE:</strong> The format of the commit message should be like this

<pre>
toaster: <short one line summary>

long(er) description

[YOCTO #0000]

Signed-off-by: First Last <name@domain.com>
</pre>

Where YOCTO #0000 is the related bug number if there is one. Signed off by with your git commit -s credentials.

We accept patches on the [https://www.yoctoproject.org/tools-resources/community/mailing-lists toaster mailing list] by "git send-email" please include in your subject line "[review-request][PATCH]"

e.g.
<code>
$ git send-email HEAD^ --subject-prefix="review-request][PATCH"
</code>

A comprehensive document about commit messages is available on the [http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines openembedded wiki]

More help learning git is available on [https://try.github.io github] and [http://git-scm.com/documentation/ the official documentation]

=== Sending branches to Toaster Project ===

If you wish to submit whole branches please use the poky-contrib repository see [[Poky Contributions#Poky_Contrib_Branch]] for setup guide.

Once you have pushed a branch please then send an email to the [https://www.yoctoproject.org/tools-resources/community/mailing-lists toaster mailing list] with the subject in the following format:

<code>
[review-request] my_branch_name
</code>

In the body of the email it's useful to describe your branch's functionality, which commits and a link to the git web.

If you need any assistance please post on the mailing list.

=== Submitting patch sets for integration into Bitbake ===

All Toaster patches need to be submitted upstream to the Bitbake repository after they have been reviewed on the Toaster mailing list. Since development happens on the poky-contrib repository, but the patches need to be merged to the Bitbake repository, the following process should be executed.

1) Bring toaster-next up to date with master
<code> git fetch poky-contrib toaster-next&& git fetch origin master</code>
<code> git checkout -b toaster-next poky-contrib/toaster-next </code>
<code> git rebase origin/master </code>

2) Checkout the target branch
<code>git checkout the/target/branch</code>

3) Create a new branch for submission
<code> git checkout -b yourname/submit/the/target/branch </code>

4) Make sure the branch is rebased on current poky-contrib toaster-next.
<code>git rebase poky-contrib/toaster-next</code>

5) Test the changes. Run the Django unit tests. People put effort into these so we should make sure we use them.
<code>bitbake/lib/toaster/manage.py test orm toastergui</code>

6) Add signed off by to the commit messages
<code>git filter-branch -f --msg-filter 'cat && echo "Signed-off-by: $(git config --get user.name) <$(git config --get user.email)>"' toaster-next..HEAD</code>

7) Push the modified commit messages and rebased version to poky-contrib
<code>git push -u poky-contrib yourname/submit/the/target/branch </code>

8) Use the create-pull-request script (from poky) to create a pull request
<code>./scripts/create-pull-request -d bitbake -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next</code>

9) Review their content, especially the summary mail:
<code>edit ./pull-<pid>/0000-cover-letter.patch</code>

10) Push the branch you just signed off on and sent upstream to toaster-next
<code> git push -f -u poky-contrib yourname/submit/the/target/branch:toaster-next </code>

When you are satisfied, you can send them with:
<code>./scripts/send-pull-request -a -p ./pull-<pid></code> -t bitbake-devel@lists.openembedded.org

==== Submitting patches for prior releases ====

The procedure is the same, but using the prior release as the base branch instead of the "master" branch in bitbake.

Also, make sure that you add the name of the prior release for which the patchset is intended in the prefix of the patchset, as parameter to the "create-pull-request" command, e.g. '''-p 1.26''' for the 1.26 branch.

==== Gotchas ====

Sometimes the mailer will refuse to send patches, especially on binary or long-line files. The proper way to go around that is to reply to the patchset you've submitted to the mailing list, asking for a git pull directly from the poky-contrib branch.
<br>
The toasterconf.json files live in the meta and meta-yocto layer. Patches to the meta-yocto/conf/toasterconf.json go to poky@yoctoproject.org. Patches to meta/conf/toasterjson.conf go to openembedded-core@lists.openembedded.org.

=== Submitting patches for documentation ===

Documentation patches should be sent to [https://lists.yoctoproject.org/listinfo/yocto Yocto mailing list] with [yocto-docs] in the subject, CC Scott Rifenbark (and make sure you send it to his gmail, not his defunct Intel address). For his email address, look at [http://lists.openembedded.org/pipermail/bitbake-devel/2015-October/006632.html this post].

== Code syle guide ==

=== Templates ===

Django has a template language which allows us to render pages based on the data (context). We use the template language to setup the initial state of the page and to create re-usable components that can be included in other pages.

The recommend template code style is as follows

'''Yes please:'''

<pre>
{{var}}

<div>
{# Maintaining indentation #}
{% if %}
<p>this</p>
{% else %}
<p>that</p>
{% endif %}
</div>

{% comment %}
This is a longer comment that describes all the things
that are below in quite a bit of detail because they're
a little more difficult to understand.
{% endcomment %}

{% for layer in layers_list %}
{{layer}}
{% endfor %}

</pre>

'''No thank you:'''
<pre>
{{var}}
<div>
{# Maintaining indentation #}
{%if%}<p>this</p>{%else%}<p>that</p>{%endif%}
</div>

{#This is a longer comment that describes all the things that are below in quite a bit of detail because they're a little more difficult to understand. #}
{%for o in layers_list%}{{o}}{%endfor%}
</pre>

Note:
* Maintain indentation as you would with other languages
* White space after '%'
* Comment blocks for longer comments

=== Javascript ===

'''Yes please:'''
<pre>

"use strict";

/* These hold some numbers */
var oneVar = 1;
var twoVar = 2;

var cheesesTypes = {
cheddar : 1,
stilton : 2,
emmental : 3,
};

function doThingsHere(){
return 1;
}

/* If one equals two do some other things and make sure that
* if the the click handler is setup correctly.
*/
if (one === two) {
var cheese = "cheddar";
oneVar = doThingsHere();

$(this).click(function (event){
alert("Hello");
});
}

$("#little-mouse").focusout(function(){
alert("bye")
});

if (oneVar)
noThingHere();
else
doThingHere();
</pre>

'''No thank you:'''
<pre>
// These hold some numbers
oneVar = 1
twoVar = 2

var cheesesTypes = { cheddar : 1, stilton : 2, emmental : 3, }

function doThingsHere ()
{
return 1;
}

//If one equals two do some other things and make sure that if the the click handler is setup correctly.
if( one === two ) {
var cheese = "cheddar";
oneVar = doThingsHere();

$(this).click(function(event){ alert("Hello"); });
}

document.getElementById("little-mouse").addEventListener("focusout", function(){
alert("bye")
});

if (oneVar)
{
noThingHere();
} else { doThingHere(); }
</pre>

Note:
* Variables should be marked with "var"
* Semicolons should be used
* Keep as close to 80 cols as possible
* Use 2 space per indentation
* Open curly braces after parenthesis for functions and close on a new line
* Use camelCase for function names and variable names

Make use of running your Javascript through jshint we have a .jshint configuration file in that js directory (toastergui/static/js)

e.g. install jshint and add to your current PATH, then run:
<code>
$ npm install jshint; export PATH=$PATH:$PWD/node_modules/.bin/
$ jshint ./toastergui/static/js/base.js
</code>

=== HTML ===

'''Yes please:'''
<pre>
<div id="something-area">
<p class="important">This is some text</p>
</div>

<div>
<p id="important-text>This is some text</p>
</div>

</pre>

'''No thank you:'''
<pre>
<div id="somethingarea">
<p class="Important">This is some text</p></div>
<div id="somethingarea">
<p id="ImportantText">This is
some text
</p>

</div>
</pre>

Note:
* 2 space indentation
* Lower case, ids hyphenated when multiple words
* No duplicate ids

* Run your HTML through a [http://validator.w3.org/#validate_by_input HTML validator] available for [http://validator.w3.org/source/ local install]. The w3c validator it's self doesn't currently validate html5, it uses as a back end [https://validator.github.io/validator/ Nu Html Checker] which can be installed as a standalone service, full instructions in the readme.

Quick install instructions:
<pre>
$ mkdir html5-validator && cd html5-validator
$ export JAVA_HOME=/usr/lib/jvm/java-6-openjdk
$ git clone https://github.com/validator/validator.git
$ python build/build.py all
$ python build/build.py all
</pre>

HTML can be indented quickly using tidy, for example:
<pre>
tidy -xml --indent auto --indent-spaces 2 --quiet yes -w -1 --show-body-only yes ./index.html
</pre>

=== Python ===

Lenient [https://www.python.org/dev/peps/pep-0008 pep8]
Ignoring most of the whitespace around character issues (E124,E203,E201,E265,E303,E302,E231) see toaster/.pep8 and [http://pep8.readthedocs.org/en/latest/intro.html#error-codes error code list]

Fix all issues identified by running code through pep8. We have a fairly lenient config file (toaster/.pep8).

e.g.
<code>
$ pep8 ./toastergui/urls.py
</code>

Run code through pylint and fix identified issues - Some can be reasonably ignored such as doc strings for every function or star-args. No pylintrc config provided here as most issues identified are highly contextual and should be ignored on a case by case basis.

<code>
$ pylint --load-plugins pylint_django toastergui/tests.py
</code>

== Working with design ==

Yes, the Yocto Project is one of those lucky projects with designers around to help in UI matters. We have a document explaining how to work with the design contributors: [[File:Working_with_design.pdf]]

Contribute to Toaster

2016-01-07T12:27:07Z

Ed: /* Submitting patches for documentation */

[[Category:Toaster]]
This page summarises the Toaster development process. We hope this will help you start contributing to the project.

== What can I do? ==

The [https://bugzilla.yoctoproject.org/buglist.cgi?product=Toaster Yocto Project Bugzilla instance] lists all the things that need to be done:

* If the issue says <strong>GUI design available</strong> in the Whiteboard field, there is a design specification document attached to the issue that you should follow. Send questions / comments about it to the [https://lists.yoctoproject.org/listinfo/toaster Toaster mailing list]
* If the issue says <strong>GUI design pending</strong> in the Whiteboard field, there is some design work still to be done. Feel free to take the issue and send an email to the [https://lists.yoctoproject.org/listinfo/toaster Toaster mailing list] to find out why the design work is not done yet

== Set up the local repository ==

For development of Toaster we recommend setting up a local install of Toaster. General install instructions are available in the main [https://www.yoctoproject.org/documentation/toaster-manual Toaster documentation]

Clone the poky repository
<code>
$ git clone git://git.yoctoproject.org/poky
$ cd poky
</code>

Install a python virtual environment to sandbox the python modules from your OS.
Enter Activate the python virtual environment in your current shell.
<code>
$ virtualenv venv
$ source ./venv/bin/activate
</code>

Install the python module dependencies for Toaster
<code>
$ pip install -r ./bitbake/toaster-requirements.txt
</code>

Run the setup and start script, follow instructions displayed
<code>
$ TOASTER_MANAGED=1 TOASTER_DEVEL=1 ./bitbake/bin/toaster
</code>

== Submitting patches ==

Publishing your patches to Toaster is a two step process.
# Sending patches to Toaster Project for review
# Submitting the patches that you reviewed to the upstream repository

Toaster code lives in Bitbake repository at [http://git.openembedded.org/bitbake/|http://git.openembedded.org/bitbake/].
All contributions must be upstreamed to the Bitbake repository in order to make it to the "master" branch of the poky/ repository.

=== Workflow ===
We are now supporting a [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/ poky-contrib] toaster-next branch. The purpose of this branch is to speed up our work so that we can base patches on top of patches that are waiting for upstream inclusion but have not yet made it into master. To facilitate this we have some extra rebasing actions needed.

1) Add poky-contrib to the local repository you set up above
<code> git remote add contrib git://git.yoctoproject.org/poky-contrib </code>

2) Start your feature branch off of toaster-next
<code> git checkout -b the/target/branch contrib/toaster-next </code>

3) Do Work

4) Rebase on toaster-next. It has probably changed while you were working (unless you are really really fast!)
<code> git rebase contrib/toaster-next </code>

5) Send to the toaster-mailing list using one of the methods outlined below.

=== Sending patches to Toaster Project ===

<strong>NOTE:</strong> The format of the commit message should be like this

<pre>
toaster: <short one line summary>

long(er) description

[YOCTO #0000]

Signed-off-by: First Last <name@domain.com>
</pre>

Where YOCTO #0000 is the related bug number if there is one. Signed off by with your git commit -s credentials.

We accept patches on the [https://www.yoctoproject.org/tools-resources/community/mailing-lists toaster mailing list] by "git send-email" please include in your subject line "[review-request][PATCH]"

e.g.
<code>
$ git send-email HEAD^ --subject-prefix="review-request][PATCH"
</code>

A comprehensive document about commit messages is available on the [http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines openembedded wiki]

More help learning git is available on [https://try.github.io github] and [http://git-scm.com/documentation/ the official documentation]

=== Sending branches to Toaster Project ===

If you wish to submit whole branches please use the poky-contrib repository see [[Poky Contributions#Poky_Contrib_Branch]] for setup guide.

Once you have pushed a branch please then send an email to the [https://www.yoctoproject.org/tools-resources/community/mailing-lists toaster mailing list] with the subject in the following format:

<code>
[review-request] my_branch_name
</code>

In the body of the email it's useful to describe your branch's functionality, which commits and a link to the git web.

If you need any assistance please post on the mailing list.

=== Submitting patch sets for integration into Bitbake ===

All Toaster patches need to be submitted upstream to the Bitbake repository after they have been reviewed on the Toaster mailing list. Since development happens on the poky-contrib repository, but the patches need to be merged to the Bitbake repository, the following process should be executed.

1) Bring toaster-next up to date with master
<code> git fetch poky-contrib toaster-next&& git fetch origin master</code>
<code> git checkout -b toaster-next poky-contrib/toaster-next </code>
<code> git rebase origin/master </code>

2) Checkout the target branch
<code>git checkout the/target/branch</code>

3) Create a new branch for submission
<code> git checkout -b yourname/submit/the/target/branch </code>

4) Make sure the branch is rebased on current poky-contrib toaster-next.
<code>git rebase poky-contrib/toaster-next</code>

5) Test the changes. Run the Django unit tests. People put effort into these so we should make sure we use them.
<code>bitbake/lib/toaster/manage.py test orm toastergui</code>

6) Add signed off by to the commit messages
<code>git filter-branch -f --msg-filter 'cat && echo "Signed-off-by: $(git config --get user.name) <$(git config --get user.email)>"' toaster-next..HEAD</code>

7) Push the modified commit messages and rebased version to poky-contrib
<code>git push -u poky-contrib yourname/submit/the/target/branch </code>

8) Use the create-pull-request script (from poky) to create a pull request
<code>./scripts/create-pull-request -d bitbake -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next</code>

9) Review their content, especially the summary mail:
<code>edit ./pull-<pid>/0000-cover-letter.patch</code>

10) Push the branch you just signed off on and sent upstream to toaster-next
<code> git push -f -u poky-contrib yourname/submit/the/target/branch:toaster-next </code>

When you are satisfied, you can send them with:
<code>./scripts/send-pull-request -a -p ./pull-<pid></code>

to bitbake-devel@lists.openembedded.org

==== Submitting patches for prior releases ====

The procedure is the same, but using the prior release as the base branch instead of the "master" branch in bitbake.

Also, make sure that you add the name of the prior release for which the patchset is intended in the prefix of the patchset, as parameter to the "create-pull-request" command, e.g. '''-p 1.26''' for the 1.26 branch.

==== Gotchas ====

Sometimes the mailer will refuse to send patches, especially on binary or long-line files. The proper way to go around that is to reply to the patchset you've submitted to the mailing list, asking for a git pull directly from the poky-contrib branch.
<br>
The toasterconf.json files live in the meta and meta-yocto layer. Patches to the meta-yocto/conf/toasterconf.json go to poky@yoctoproject.org. Patches to meta/conf/toasterjson.conf go to openembedded-core@lists.openembedded.org.

=== Submitting patches for documentation ===

Documentation patches should be sent to [https://lists.yoctoproject.org/listinfo/yocto Yocto mailing list] with [yocto-docs] in the subject, CC Scott Rifenbark (and make sure you send it to his gmail, not his defunct Intel address). For his email address, look at [http://lists.openembedded.org/pipermail/bitbake-devel/2015-October/006632.html this post].

== Code syle guide ==

=== Templates ===

Django has a template language which allows us to render pages based on the data (context). We use the template language to setup the initial state of the page and to create re-usable components that can be included in other pages.

The recommend template code style is as follows

'''Yes please:'''

<pre>
{{var}}

<div>
{# Maintaining indentation #}
{% if %}
<p>this</p>
{% else %}
<p>that</p>
{% endif %}
</div>

{% comment %}
This is a longer comment that describes all the things
that are below in quite a bit of detail because they're
a little more difficult to understand.
{% endcomment %}

{% for layer in layers_list %}
{{layer}}
{% endfor %}

</pre>

'''No thank you:'''
<pre>
{{var}}
<div>
{# Maintaining indentation #}
{%if%}<p>this</p>{%else%}<p>that</p>{%endif%}
</div>

{#This is a longer comment that describes all the things that are below in quite a bit of detail because they're a little more difficult to understand. #}
{%for o in layers_list%}{{o}}{%endfor%}
</pre>

Note:
* Maintain indentation as you would with other languages
* White space after '%'
* Comment blocks for longer comments

=== Javascript ===

'''Yes please:'''
<pre>

"use strict";

/* These hold some numbers */
var oneVar = 1;
var twoVar = 2;

var cheesesTypes = {
cheddar : 1,
stilton : 2,
emmental : 3,
};

function doThingsHere(){
return 1;
}

/* If one equals two do some other things and make sure that
* if the the click handler is setup correctly.
*/
if (one === two) {
var cheese = "cheddar";
oneVar = doThingsHere();

$(this).click(function (event){
alert("Hello");
});
}

$("#little-mouse").focusout(function(){
alert("bye")
});

if (oneVar)
noThingHere();
else
doThingHere();
</pre>

'''No thank you:'''
<pre>
// These hold some numbers
oneVar = 1
twoVar = 2

var cheesesTypes = { cheddar : 1, stilton : 2, emmental : 3, }

function doThingsHere ()
{
return 1;
}

//If one equals two do some other things and make sure that if the the click handler is setup correctly.
if( one === two ) {
var cheese = "cheddar";
oneVar = doThingsHere();

$(this).click(function(event){ alert("Hello"); });
}

document.getElementById("little-mouse").addEventListener("focusout", function(){
alert("bye")
});

if (oneVar)
{
noThingHere();
} else { doThingHere(); }
</pre>

Note:
* Variables should be marked with "var"
* Semicolons should be used
* Keep as close to 80 cols as possible
* Use 2 space per indentation
* Open curly braces after parenthesis for functions and close on a new line
* Use camelCase for function names and variable names

Make use of running your Javascript through jshint we have a .jshint configuration file in that js directory (toastergui/static/js)

e.g. install jshint and add to your current PATH, then run:
<code>
$ npm install jshint; export PATH=$PATH:$PWD/node_modules/.bin/
$ jshint ./toastergui/static/js/base.js
</code>

=== HTML ===

'''Yes please:'''
<pre>
<div id="something-area">
<p class="important">This is some text</p>
</div>

<div>
<p id="important-text>This is some text</p>
</div>

</pre>

'''No thank you:'''
<pre>
<div id="somethingarea">
<p class="Important">This is some text</p></div>
<div id="somethingarea">
<p id="ImportantText">This is
some text
</p>

</div>
</pre>

Note:
* 2 space indentation
* Lower case, ids hyphenated when multiple words
* No duplicate ids

* Run your HTML through a [http://validator.w3.org/#validate_by_input HTML validator] available for [http://validator.w3.org/source/ local install]. The w3c validator it's self doesn't currently validate html5, it uses as a back end [https://validator.github.io/validator/ Nu Html Checker] which can be installed as a standalone service, full instructions in the readme.

Quick install instructions:
<pre>
$ mkdir html5-validator && cd html5-validator
$ export JAVA_HOME=/usr/lib/jvm/java-6-openjdk
$ git clone https://github.com/validator/validator.git
$ python build/build.py all
$ python build/build.py all
</pre>

HTML can be indented quickly using tidy, for example:
<pre>
tidy -xml --indent auto --indent-spaces 2 --quiet yes -w -1 --show-body-only yes ./index.html
</pre>

=== Python ===

Lenient [https://www.python.org/dev/peps/pep-0008 pep8]
Ignoring most of the whitespace around character issues (E124,E203,E201,E265,E303,E302,E231) see toaster/.pep8 and [http://pep8.readthedocs.org/en/latest/intro.html#error-codes error code list]

Fix all issues identified by running code through pep8. We have a fairly lenient config file (toaster/.pep8).

e.g.
<code>
$ pep8 ./toastergui/urls.py
</code>

Run code through pylint and fix identified issues - Some can be reasonably ignored such as doc strings for every function or star-args. No pylintrc config provided here as most issues identified are highly contextual and should be ignored on a case by case basis.

<code>
$ pylint --load-plugins pylint_django toastergui/tests.py
</code>

== Working with design ==

Yes, the Yocto Project is one of those lucky projects with designers around to help in UI matters. We have a document explaining how to work with the design contributors: [[File:Working_with_design.pdf]]

Contribute to Toaster

2016-01-07T12:24:17Z

Ed: /* Submitting patches for documentation */

[[Category:Toaster]]
This page summarises the Toaster development process. We hope this will help you start contributing to the project.

== What can I do? ==

The [https://bugzilla.yoctoproject.org/buglist.cgi?product=Toaster Yocto Project Bugzilla instance] lists all the things that need to be done:

* If the issue says <strong>GUI design available</strong> in the Whiteboard field, there is a design specification document attached to the issue that you should follow. Send questions / comments about it to the [https://lists.yoctoproject.org/listinfo/toaster Toaster mailing list]
* If the issue says <strong>GUI design pending</strong> in the Whiteboard field, there is some design work still to be done. Feel free to take the issue and send an email to the [https://lists.yoctoproject.org/listinfo/toaster Toaster mailing list] to find out why the design work is not done yet

== Set up the local repository ==

For development of Toaster we recommend setting up a local install of Toaster. General install instructions are available in the main [https://www.yoctoproject.org/documentation/toaster-manual Toaster documentation]

Clone the poky repository
<code>
$ git clone git://git.yoctoproject.org/poky
$ cd poky
</code>

Install a python virtual environment to sandbox the python modules from your OS.
Enter Activate the python virtual environment in your current shell.
<code>
$ virtualenv venv
$ source ./venv/bin/activate
</code>

Install the python module dependencies for Toaster
<code>
$ pip install -r ./bitbake/toaster-requirements.txt
</code>

Run the setup and start script, follow instructions displayed
<code>
$ TOASTER_MANAGED=1 TOASTER_DEVEL=1 ./bitbake/bin/toaster
</code>

== Submitting patches ==

Publishing your patches to Toaster is a two step process.
# Sending patches to Toaster Project for review
# Submitting the patches that you reviewed to the upstream repository

Toaster code lives in Bitbake repository at [http://git.openembedded.org/bitbake/|http://git.openembedded.org/bitbake/].
All contributions must be upstreamed to the Bitbake repository in order to make it to the "master" branch of the poky/ repository.

=== Workflow ===
We are now supporting a [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/ poky-contrib] toaster-next branch. The purpose of this branch is to speed up our work so that we can base patches on top of patches that are waiting for upstream inclusion but have not yet made it into master. To facilitate this we have some extra rebasing actions needed.

1) Add poky-contrib to the local repository you set up above
<code> git remote add contrib git://git.yoctoproject.org/poky-contrib </code>

2) Start your feature branch off of toaster-next
<code> git checkout -b the/target/branch contrib/toaster-next </code>

3) Do Work

4) Rebase on toaster-next. It has probably changed while you were working (unless you are really really fast!)
<code> git rebase contrib/toaster-next </code>

5) Send to the toaster-mailing list using one of the methods outlined below.

=== Sending patches to Toaster Project ===

<strong>NOTE:</strong> The format of the commit message should be like this

<pre>
toaster: <short one line summary>

long(er) description

[YOCTO #0000]

Signed-off-by: First Last <name@domain.com>
</pre>

Where YOCTO #0000 is the related bug number if there is one. Signed off by with your git commit -s credentials.

We accept patches on the [https://www.yoctoproject.org/tools-resources/community/mailing-lists toaster mailing list] by "git send-email" please include in your subject line "[review-request][PATCH]"

e.g.
<code>
$ git send-email HEAD^ --subject-prefix="review-request][PATCH"
</code>

A comprehensive document about commit messages is available on the [http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines openembedded wiki]

More help learning git is available on [https://try.github.io github] and [http://git-scm.com/documentation/ the official documentation]

=== Sending branches to Toaster Project ===

If you wish to submit whole branches please use the poky-contrib repository see [[Poky Contributions#Poky_Contrib_Branch]] for setup guide.

Once you have pushed a branch please then send an email to the [https://www.yoctoproject.org/tools-resources/community/mailing-lists toaster mailing list] with the subject in the following format:

<code>
[review-request] my_branch_name
</code>

In the body of the email it's useful to describe your branch's functionality, which commits and a link to the git web.

If you need any assistance please post on the mailing list.

=== Submitting patch sets for integration into Bitbake ===

All Toaster patches need to be submitted upstream to the Bitbake repository after they have been reviewed on the Toaster mailing list. Since development happens on the poky-contrib repository, but the patches need to be merged to the Bitbake repository, the following process should be executed.

1) Bring toaster-next up to date with master
<code> git fetch poky-contrib toaster-next&& git fetch origin master</code>
<code> git checkout -b toaster-next poky-contrib/toaster-next </code>
<code> git rebase origin/master </code>

2) Checkout the target branch
<code>git checkout the/target/branch</code>

3) Create a new branch for submission
<code> git checkout -b yourname/submit/the/target/branch </code>

4) Make sure the branch is rebased on current poky-contrib toaster-next.
<code>git rebase poky-contrib/toaster-next</code>

5) Test the changes. Run the Django unit tests. People put effort into these so we should make sure we use them.
<code>bitbake/lib/toaster/manage.py test orm toastergui</code>

6) Add signed off by to the commit messages
<code>git filter-branch -f --msg-filter 'cat && echo "Signed-off-by: $(git config --get user.name) <$(git config --get user.email)>"' toaster-next..HEAD</code>

7) Push the modified commit messages and rebased version to poky-contrib
<code>git push -u poky-contrib yourname/submit/the/target/branch </code>

8) Use the create-pull-request script (from poky) to create a pull request
<code>./scripts/create-pull-request -d bitbake -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next</code>

9) Review their content, especially the summary mail:
<code>edit ./pull-<pid>/0000-cover-letter.patch</code>

10) Push the branch you just signed off on and sent upstream to toaster-next
<code> git push -f -u poky-contrib yourname/submit/the/target/branch:toaster-next </code>

When you are satisfied, you can send them with:
<code>./scripts/send-pull-request -a -p ./pull-<pid></code>

to bitbake-devel@lists.openembedded.org

==== Submitting patches for prior releases ====

The procedure is the same, but using the prior release as the base branch instead of the "master" branch in bitbake.

Also, make sure that you add the name of the prior release for which the patchset is intended in the prefix of the patchset, as parameter to the "create-pull-request" command, e.g. '''-p 1.26''' for the 1.26 branch.

==== Gotchas ====

Sometimes the mailer will refuse to send patches, especially on binary or long-line files. The proper way to go around that is to reply to the patchset you've submitted to the mailing list, asking for a git pull directly from the poky-contrib branch.
<br>
The toasterconf.json files live in the meta and meta-yocto layer. Patches to the meta-yocto/conf/toasterconf.json go to poky@yoctoproject.org. Patches to meta/conf/toasterjson.conf go to openembedded-core@lists.openembedded.org.

=== Submitting patches for documentation ===

Documentation patches should be sent to [https://lists.yoctoproject.org/listinfo/yocto Yocto mailing list] with [yocto-docs] in the subject, CC Scott Rifenbark (and make sure you send it to his gmail, not his defunct Intel address)

== Code syle guide ==

=== Templates ===

Django has a template language which allows us to render pages based on the data (context). We use the template language to setup the initial state of the page and to create re-usable components that can be included in other pages.

The recommend template code style is as follows

'''Yes please:'''

<pre>
{{var}}

<div>
{# Maintaining indentation #}
{% if %}
<p>this</p>
{% else %}
<p>that</p>
{% endif %}
</div>

{% comment %}
This is a longer comment that describes all the things
that are below in quite a bit of detail because they're
a little more difficult to understand.
{% endcomment %}

{% for layer in layers_list %}
{{layer}}
{% endfor %}

</pre>

'''No thank you:'''
<pre>
{{var}}
<div>
{# Maintaining indentation #}
{%if%}<p>this</p>{%else%}<p>that</p>{%endif%}
</div>

{#This is a longer comment that describes all the things that are below in quite a bit of detail because they're a little more difficult to understand. #}
{%for o in layers_list%}{{o}}{%endfor%}
</pre>

Note:
* Maintain indentation as you would with other languages
* White space after '%'
* Comment blocks for longer comments

=== Javascript ===

'''Yes please:'''
<pre>

"use strict";

/* These hold some numbers */
var oneVar = 1;
var twoVar = 2;

var cheesesTypes = {
cheddar : 1,
stilton : 2,
emmental : 3,
};

function doThingsHere(){
return 1;
}

/* If one equals two do some other things and make sure that
* if the the click handler is setup correctly.
*/
if (one === two) {
var cheese = "cheddar";
oneVar = doThingsHere();

$(this).click(function (event){
alert("Hello");
});
}

$("#little-mouse").focusout(function(){
alert("bye")
});

if (oneVar)
noThingHere();
else
doThingHere();
</pre>

'''No thank you:'''
<pre>
// These hold some numbers
oneVar = 1
twoVar = 2

var cheesesTypes = { cheddar : 1, stilton : 2, emmental : 3, }

function doThingsHere ()
{
return 1;
}

//If one equals two do some other things and make sure that if the the click handler is setup correctly.
if( one === two ) {
var cheese = "cheddar";
oneVar = doThingsHere();

$(this).click(function(event){ alert("Hello"); });
}

document.getElementById("little-mouse").addEventListener("focusout", function(){
alert("bye")
});

if (oneVar)
{
noThingHere();
} else { doThingHere(); }
</pre>

Note:
* Variables should be marked with "var"
* Semicolons should be used
* Keep as close to 80 cols as possible
* Use 2 space per indentation
* Open curly braces after parenthesis for functions and close on a new line
* Use camelCase for function names and variable names

Make use of running your Javascript through jshint we have a .jshint configuration file in that js directory (toastergui/static/js)

e.g. install jshint and add to your current PATH, then run:
<code>
$ npm install jshint; export PATH=$PATH:$PWD/node_modules/.bin/
$ jshint ./toastergui/static/js/base.js
</code>

=== HTML ===

'''Yes please:'''
<pre>
<div id="something-area">
<p class="important">This is some text</p>
</div>

<div>
<p id="important-text>This is some text</p>
</div>

</pre>

'''No thank you:'''
<pre>
<div id="somethingarea">
<p class="Important">This is some text</p></div>
<div id="somethingarea">
<p id="ImportantText">This is
some text
</p>

</div>
</pre>

Note:
* 2 space indentation
* Lower case, ids hyphenated when multiple words
* No duplicate ids

* Run your HTML through a [http://validator.w3.org/#validate_by_input HTML validator] available for [http://validator.w3.org/source/ local install]. The w3c validator it's self doesn't currently validate html5, it uses as a back end [https://validator.github.io/validator/ Nu Html Checker] which can be installed as a standalone service, full instructions in the readme.

Quick install instructions:
<pre>
$ mkdir html5-validator && cd html5-validator
$ export JAVA_HOME=/usr/lib/jvm/java-6-openjdk
$ git clone https://github.com/validator/validator.git
$ python build/build.py all
$ python build/build.py all
</pre>

HTML can be indented quickly using tidy, for example:
<pre>
tidy -xml --indent auto --indent-spaces 2 --quiet yes -w -1 --show-body-only yes ./index.html
</pre>

=== Python ===

Lenient [https://www.python.org/dev/peps/pep-0008 pep8]
Ignoring most of the whitespace around character issues (E124,E203,E201,E265,E303,E302,E231) see toaster/.pep8 and [http://pep8.readthedocs.org/en/latest/intro.html#error-codes error code list]

Fix all issues identified by running code through pep8. We have a fairly lenient config file (toaster/.pep8).

e.g.
<code>
$ pep8 ./toastergui/urls.py
</code>

Run code through pylint and fix identified issues - Some can be reasonably ignored such as doc strings for every function or star-args. No pylintrc config provided here as most issues identified are highly contextual and should be ignored on a case by case basis.

<code>
$ pylint --load-plugins pylint_django toastergui/tests.py
</code>

== Working with design ==

Yes, the Yocto Project is one of those lucky projects with designers around to help in UI matters. We have a document explaining how to work with the design contributors: [[File:Working_with_design.pdf]]

Contribute to Toaster

2016-01-07T12:20:43Z

Ed:

[[Category:Toaster]]
This page summarises the Toaster development process. We hope this will help you start contributing to the project.

== What can I do? ==

The [https://bugzilla.yoctoproject.org/buglist.cgi?product=Toaster Yocto Project Bugzilla instance] lists all the things that need to be done:

* If the issue says <strong>GUI design available</strong> in the Whiteboard field, there is a design specification document attached to the issue that you should follow. Send questions / comments about it to the [https://lists.yoctoproject.org/listinfo/toaster Toaster mailing list]
* If the issue says <strong>GUI design pending</strong> in the Whiteboard field, there is some design work still to be done. Feel free to take the issue and send an email to the [https://lists.yoctoproject.org/listinfo/toaster Toaster mailing list] to find out why the design work is not done yet

== Set up the local repository ==

For development of Toaster we recommend setting up a local install of Toaster. General install instructions are available in the main [https://www.yoctoproject.org/documentation/toaster-manual Toaster documentation]

Clone the poky repository
<code>
$ git clone git://git.yoctoproject.org/poky
$ cd poky
</code>

Install a python virtual environment to sandbox the python modules from your OS.
Enter Activate the python virtual environment in your current shell.
<code>
$ virtualenv venv
$ source ./venv/bin/activate
</code>

Install the python module dependencies for Toaster
<code>
$ pip install -r ./bitbake/toaster-requirements.txt
</code>

Run the setup and start script, follow instructions displayed
<code>
$ TOASTER_MANAGED=1 TOASTER_DEVEL=1 ./bitbake/bin/toaster
</code>

== Submitting patches ==

Publishing your patches to Toaster is a two step process.
# Sending patches to Toaster Project for review
# Submitting the patches that you reviewed to the upstream repository

Toaster code lives in Bitbake repository at [http://git.openembedded.org/bitbake/|http://git.openembedded.org/bitbake/].
All contributions must be upstreamed to the Bitbake repository in order to make it to the "master" branch of the poky/ repository.

=== Workflow ===
We are now supporting a [http://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/ poky-contrib] toaster-next branch. The purpose of this branch is to speed up our work so that we can base patches on top of patches that are waiting for upstream inclusion but have not yet made it into master. To facilitate this we have some extra rebasing actions needed.

1) Add poky-contrib to the local repository you set up above
<code> git remote add contrib git://git.yoctoproject.org/poky-contrib </code>

2) Start your feature branch off of toaster-next
<code> git checkout -b the/target/branch contrib/toaster-next </code>

3) Do Work

4) Rebase on toaster-next. It has probably changed while you were working (unless you are really really fast!)
<code> git rebase contrib/toaster-next </code>

5) Send to the toaster-mailing list using one of the methods outlined below.

=== Sending patches to Toaster Project ===

<strong>NOTE:</strong> The format of the commit message should be like this

<pre>
toaster: <short one line summary>

long(er) description

[YOCTO #0000]

Signed-off-by: First Last <name@domain.com>
</pre>

Where YOCTO #0000 is the related bug number if there is one. Signed off by with your git commit -s credentials.

We accept patches on the [https://www.yoctoproject.org/tools-resources/community/mailing-lists toaster mailing list] by "git send-email" please include in your subject line "[review-request][PATCH]"

e.g.
<code>
$ git send-email HEAD^ --subject-prefix="review-request][PATCH"
</code>

A comprehensive document about commit messages is available on the [http://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines openembedded wiki]

More help learning git is available on [https://try.github.io github] and [http://git-scm.com/documentation/ the official documentation]

=== Sending branches to Toaster Project ===

If you wish to submit whole branches please use the poky-contrib repository see [[Poky Contributions#Poky_Contrib_Branch]] for setup guide.

Once you have pushed a branch please then send an email to the [https://www.yoctoproject.org/tools-resources/community/mailing-lists toaster mailing list] with the subject in the following format:

<code>
[review-request] my_branch_name
</code>

In the body of the email it's useful to describe your branch's functionality, which commits and a link to the git web.

If you need any assistance please post on the mailing list.

=== Submitting patch sets for integration into Bitbake ===

All Toaster patches need to be submitted upstream to the Bitbake repository after they have been reviewed on the Toaster mailing list. Since development happens on the poky-contrib repository, but the patches need to be merged to the Bitbake repository, the following process should be executed.

1) Bring toaster-next up to date with master
<code> git fetch poky-contrib toaster-next&& git fetch origin master</code>
<code> git checkout -b toaster-next poky-contrib/toaster-next </code>
<code> git rebase origin/master </code>

2) Checkout the target branch
<code>git checkout the/target/branch</code>

3) Create a new branch for submission
<code> git checkout -b yourname/submit/the/target/branch </code>

4) Make sure the branch is rebased on current poky-contrib toaster-next.
<code>git rebase poky-contrib/toaster-next</code>

5) Test the changes. Run the Django unit tests. People put effort into these so we should make sure we use them.
<code>bitbake/lib/toaster/manage.py test orm toastergui</code>

6) Add signed off by to the commit messages
<code>git filter-branch -f --msg-filter 'cat && echo "Signed-off-by: $(git config --get user.name) <$(git config --get user.email)>"' toaster-next..HEAD</code>

7) Push the modified commit messages and rebased version to poky-contrib
<code>git push -u poky-contrib yourname/submit/the/target/branch </code>

8) Use the create-pull-request script (from poky) to create a pull request
<code>./scripts/create-pull-request -d bitbake -s "toaster: Fixes and clean ups" -u poky-contrib -r poky-contrib/toaster-next</code>

9) Review their content, especially the summary mail:
<code>edit ./pull-<pid>/0000-cover-letter.patch</code>

10) Push the branch you just signed off on and sent upstream to toaster-next
<code> git push -f -u poky-contrib yourname/submit/the/target/branch:toaster-next </code>

When you are satisfied, you can send them with:
<code>./scripts/send-pull-request -a -p ./pull-<pid></code>

to bitbake-devel@lists.openembedded.org

==== Submitting patches for prior releases ====

The procedure is the same, but using the prior release as the base branch instead of the "master" branch in bitbake.

Also, make sure that you add the name of the prior release for which the patchset is intended in the prefix of the patchset, as parameter to the "create-pull-request" command, e.g. '''-p 1.26''' for the 1.26 branch.

==== Gotchas ====

Sometimes the mailer will refuse to send patches, especially on binary or long-line files. The proper way to go around that is to reply to the patchset you've submitted to the mailing list, asking for a git pull directly from the poky-contrib branch.
<br>
The toasterconf.json files live in the meta and meta-yocto layer. Patches to the meta-yocto/conf/toasterconf.json go to poky@yoctoproject.org. Patches to meta/conf/toasterjson.conf go to openembedded-core@lists.openembedded.org.

=== Submitting patches for documentation ===

Documentation patches should be sent to [https://lists.yoctoproject.org/listinfo/yocto Yocto mailing list] with [yocto-docs] in the subject, CC Scott (and make sure you send it to his gmail, not his defunct Intel address)

== Code syle guide ==

=== Templates ===

Django has a template language which allows us to render pages based on the data (context). We use the template language to setup the initial state of the page and to create re-usable components that can be included in other pages.

The recommend template code style is as follows

'''Yes please:'''

<pre>
{{var}}

<div>
{# Maintaining indentation #}
{% if %}
<p>this</p>
{% else %}
<p>that</p>
{% endif %}
</div>

{% comment %}
This is a longer comment that describes all the things
that are below in quite a bit of detail because they're
a little more difficult to understand.
{% endcomment %}

{% for layer in layers_list %}
{{layer}}
{% endfor %}

</pre>

'''No thank you:'''
<pre>
{{var}}
<div>
{# Maintaining indentation #}
{%if%}<p>this</p>{%else%}<p>that</p>{%endif%}
</div>

{#This is a longer comment that describes all the things that are below in quite a bit of detail because they're a little more difficult to understand. #}
{%for o in layers_list%}{{o}}{%endfor%}
</pre>

Note:
* Maintain indentation as you would with other languages
* White space after '%'
* Comment blocks for longer comments

=== Javascript ===

'''Yes please:'''
<pre>

"use strict";

/* These hold some numbers */
var oneVar = 1;
var twoVar = 2;

var cheesesTypes = {
cheddar : 1,
stilton : 2,
emmental : 3,
};

function doThingsHere(){
return 1;
}

/* If one equals two do some other things and make sure that
* if the the click handler is setup correctly.
*/
if (one === two) {
var cheese = "cheddar";
oneVar = doThingsHere();

$(this).click(function (event){
alert("Hello");
});
}

$("#little-mouse").focusout(function(){
alert("bye")
});

if (oneVar)
noThingHere();
else
doThingHere();
</pre>

'''No thank you:'''
<pre>
// These hold some numbers
oneVar = 1
twoVar = 2

var cheesesTypes = { cheddar : 1, stilton : 2, emmental : 3, }

function doThingsHere ()
{
return 1;
}

//If one equals two do some other things and make sure that if the the click handler is setup correctly.
if( one === two ) {
var cheese = "cheddar";
oneVar = doThingsHere();

$(this).click(function(event){ alert("Hello"); });
}

document.getElementById("little-mouse").addEventListener("focusout", function(){
alert("bye")
});

if (oneVar)
{
noThingHere();
} else { doThingHere(); }
</pre>

Note:
* Variables should be marked with "var"
* Semicolons should be used
* Keep as close to 80 cols as possible
* Use 2 space per indentation
* Open curly braces after parenthesis for functions and close on a new line
* Use camelCase for function names and variable names

Make use of running your Javascript through jshint we have a .jshint configuration file in that js directory (toastergui/static/js)

e.g. install jshint and add to your current PATH, then run:
<code>
$ npm install jshint; export PATH=$PATH:$PWD/node_modules/.bin/
$ jshint ./toastergui/static/js/base.js
</code>

=== HTML ===

'''Yes please:'''
<pre>
<div id="something-area">
<p class="important">This is some text</p>
</div>

<div>
<p id="important-text>This is some text</p>
</div>

</pre>

'''No thank you:'''
<pre>
<div id="somethingarea">
<p class="Important">This is some text</p></div>
<div id="somethingarea">
<p id="ImportantText">This is
some text
</p>

</div>
</pre>

Note:
* 2 space indentation
* Lower case, ids hyphenated when multiple words
* No duplicate ids

* Run your HTML through a [http://validator.w3.org/#validate_by_input HTML validator] available for [http://validator.w3.org/source/ local install]. The w3c validator it's self doesn't currently validate html5, it uses as a back end [https://validator.github.io/validator/ Nu Html Checker] which can be installed as a standalone service, full instructions in the readme.

Quick install instructions:
<pre>
$ mkdir html5-validator && cd html5-validator
$ export JAVA_HOME=/usr/lib/jvm/java-6-openjdk
$ git clone https://github.com/validator/validator.git
$ python build/build.py all
$ python build/build.py all
</pre>

HTML can be indented quickly using tidy, for example:
<pre>
tidy -xml --indent auto --indent-spaces 2 --quiet yes -w -1 --show-body-only yes ./index.html
</pre>

=== Python ===

Lenient [https://www.python.org/dev/peps/pep-0008 pep8]
Ignoring most of the whitespace around character issues (E124,E203,E201,E265,E303,E302,E231) see toaster/.pep8 and [http://pep8.readthedocs.org/en/latest/intro.html#error-codes error code list]

Fix all issues identified by running code through pep8. We have a fairly lenient config file (toaster/.pep8).

e.g.
<code>
$ pep8 ./toastergui/urls.py
</code>

Run code through pylint and fix identified issues - Some can be reasonably ignored such as doc strings for every function or star-args. No pylintrc config provided here as most issues identified are highly contextual and should be ignored on a case by case basis.

<code>
$ pylint --load-plugins pylint_django toastergui/tests.py
</code>

== Working with design ==

Yes, the Yocto Project is one of those lucky projects with designers around to help in UI matters. We have a document explaining how to work with the design contributors: [[File:Working_with_design.pdf]]

Toaster future release planning

2015-10-23T16:56:12Z

Ed: /* Ed's */

[[Category:Toaster]]

== 2.1 Planning ==

=== Wish lists ===

==== Michael's ====
* Finish image-customisation 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Remove pseudo API cruft / template context to json response stuff
* Consolidate used API into it's own view
* Finish toaster tables porting
* Get selenium test wrapper
* Create a toasterclient.py to interact with toaster to avoid need for 'command line builds'
** This would use toaster's API as the entry point to using bitbake
** It could be called by CI systems
** It could be used by auto builders etc
** Means that there are no two modes anywhere in Toaster
** Allows project configuration to be changed in toaster from the command line

==== Brian's ====
This is *not* ordered! This is more of a brain dump :)
* Collapse analysis and managed mode
* Working CI for each commit into toaster-next as well as for project peoples testME branches on poky-contrib:
** run django tests
** run selenium tests
** leverage sstate to make runs generally shorter
* remove git assumptions from code
* rationalize/simplify the configuration scripts
* if bitbake-memres comes out, interact with it gracefully (this is my preferred method of collapsing analysis and managed)
* fix the tmpdir/release build issue &/or discuss the need to support building old releases with a UI rather than limiting toaster to build the release it is part of. This is inherently fragile.
* ask bb to parse any layer added to a project and such as imported layers, and layers specified in the configuration file to give us recipe information.
* improve our build event following:
** note parse events
** update/retrieve ui so that we can tell something is happening before the first build event comes
** eliminate the remaining random tracebacks from try/except failures.
* allow configuration in addition to the addition/removal of layers/packages
** kernel config
* add user control/authentication
* update to Django 1.8. Always stay on Django LTS versions
* add layer update from layers.openembedded.org to the UI
* add Django tests for building e.g. we should be able to build core-image-sato from a django test and validate the db
* add mysql script to simplify setup with mysql/apache
* pull in new look and feel
* add django tests to validate all artifacts - if we say they can download it and it appears on a page anywhere, it should have a test
* improve docs of code on wiki. We have a nice start (ty E & M); I'd like to improve it.
** events - more info and list types supported
** what logic is in jscript , what is in python
** database schema definition and description esp interrelationships.
** list django tests, mostly so we can see what we are missing.
* build mode triggerred off of database entry, not autonomous process.
* add asynchronicity. I have noted a number of places where commands result in a sluggish ui. I'm nervous about this one.
** for example, starting a build that requires us to clone layers has a noticeable delay as compared to starting a local only project build.
* verify we can stop builds cleanly.
* get the rest of our logs into our local toaster dir
* allow us to run and stop 2 toasters on the same machine without them interfering with each other
* (2.2 or later for sure) discuss how to support multiple back end bb servers.
** probably will need to be able to add servers/remove servers/see server status/build state
* be able to see more details about build. For example, see the "jobs" being processed like you can in knotty
* revisit what variables we let people change. sstate_dir and dl_dir should certainly be allowed to change
* discuss way we do migrations. possibly change. thoughts:
** only support migrations from last release to current. (e.g. if you were running toaster jethro you could update to jethro++, but could not from fido to jethro)
** take migration from the startup script. it's only for releasetorelease.
*** allow it to be in for master and ease of development w/in a release and pull at end as we do with moving releases.
** whatever we decide, add a test set for it so we know it works
* Be able to delete things from the ui
** old builds
** old projects
** imported layers we no longer want
* Be able to set from the ui a policy to delete all builds/recipes/packages that are older than XXX &/or be able to set maximum size on db and delete everything older than XXX when we near that size
* update the builds on the web page so we dont have to hit refresh to see the build progress.

==== Elliot's ====

* Make sure all files lint properly
* Include lint in CI builds
* Improve test coverage of all areas of the UI and back-end
* Clean up toasterui.py so it's easier to see what's going on in there
* Fix localhostbecontroller so it doesn't rely on what's in the log file when figuring out whether the bitbake server has started
* Provide a way to modify settings in settings.py without editing that file (e.g. with a local overlay configuration file)
* Move the logic, environment variables, directory setup and script calls from bin/toaster into Django commands: this would allow you to run toaster correctly, with all the required setup, without having to use bin/toaster; it would also mean that we could provide cleaner production setup instructions, as a user could run a series of Django commands (with their own parameters) to setup their environment; bin/toaster would then just execute a series of Django commands

==== Belén's ====

* Finish image customisation. Related bugs: 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Review interaction with layers: as it is, imposes heavy restrictions on users. Some of the questions I would like to consider:
** Should the import layer action be global instead of per project, so that you can reuse imported layers across projects?
** Should we allow users to override the release layer branch, setting a particular layer index layer to a different branch or commit?
** Should we allow users to set a different git repo for layer index layers?
** Should we allow users to override the bitbake revision set by the release in a project?
** Related bugs: 6640, 6701, 7574, 8426, 8429
* Access control (a simple one to start, with very basic permissions). Related bugs: 6233, 6234
* WIC integration (getting a step closer to the holy grail of 'click button' > 'image deployed in board')
* Fix the variable history (this is one of the features users have highly praised, and it is a bit broken in 2.0). Related bugs: 5811, 8488, 8190, 8189, 8188
* Get Toaster to collect build data from Jenkins builds. Once again, repeatedly requested by users. Related bugs: 7527

==== Ed's ====

* Merge analysis and managed modes
* Fix as much pending bugs as possible.
* Finish image customisation.
* Support Django LTS
* Increase test coverage. It would be good to set realistic goals, e.g. cover specific modules or increase coverage to 10% and follow the plan.
* Include production configuration into testing
* Cover views.py with tests and split it into modules. Currently it's huge and hard to maintain. I suspect there are a lot of unused APIs in there.
* Finish refactoring of buildcontroller code. This work is started in ed/toaster/bec and sitting there for quite long time.
* Bring patchset support to toaster patchwork.
* Add 'submitted upstream' and 'merged upstream' statuses to patchwork. Make the statuses updated automatically when patch is accepted to toaster-next or bitbake master.
* Clean up the code. Set realistic goals for pylint scores and follow them.
* Enhance Jenkins CI jobs to run all possible django, tts and pylint tests

== All bugs for 2.1+ ==

{{#bugzilla:
|columns=id,milestone,summary,status,priority
|milestone=future,2.1,2.1 M1,2.1 M2,2.1 M3,2.1 M4
|sort=priority
|product=Toaster
|status=!resolved
}}

[https://bugzilla.yoctoproject.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ACCEPTED&bug_status=IN%20PROGRESS%20DESIGN&bug_status=IN%20PROGRESS%20DESIGN%20COMPLETE&bug_status=IN%20PROGRESS%20IMPLEMENTATION&bug_status=IN%20PROGRESS%20REVIEW&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&columnlist=product%2Cbug_status%2Cshort_desc%2Cchangeddate%2Ctarget_milestone&component=toaster&f1=target_milestone&list_id=476868&o1=greaterthan&product=Toaster&query_format=advanced&resolution=---&v1=2.0&query_based_on= Bugzilla query]

Toaster future release planning

2015-10-23T16:55:15Z

Ed: /* Ed's */

[[Category:Toaster]]

== 2.1 Planning ==

=== Wish lists ===

==== Michael's ====
* Finish image-customisation 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Remove pseudo API cruft / template context to json response stuff
* Consolidate used API into it's own view
* Finish toaster tables porting
* Get selenium test wrapper
* Create a toasterclient.py to interact with toaster to avoid need for 'command line builds'
** This would use toaster's API as the entry point to using bitbake
** It could be called by CI systems
** It could be used by auto builders etc
** Means that there are no two modes anywhere in Toaster
** Allows project configuration to be changed in toaster from the command line

==== Brian's ====
This is *not* ordered! This is more of a brain dump :)
* Collapse analysis and managed mode
* Working CI for each commit into toaster-next as well as for project peoples testME branches on poky-contrib:
** run django tests
** run selenium tests
** leverage sstate to make runs generally shorter
* remove git assumptions from code
* rationalize/simplify the configuration scripts
* if bitbake-memres comes out, interact with it gracefully (this is my preferred method of collapsing analysis and managed)
* fix the tmpdir/release build issue &/or discuss the need to support building old releases with a UI rather than limiting toaster to build the release it is part of. This is inherently fragile.
* ask bb to parse any layer added to a project and such as imported layers, and layers specified in the configuration file to give us recipe information.
* improve our build event following:
** note parse events
** update/retrieve ui so that we can tell something is happening before the first build event comes
** eliminate the remaining random tracebacks from try/except failures.
* allow configuration in addition to the addition/removal of layers/packages
** kernel config
* add user control/authentication
* update to Django 1.8. Always stay on Django LTS versions
* add layer update from layers.openembedded.org to the UI
* add Django tests for building e.g. we should be able to build core-image-sato from a django test and validate the db
* add mysql script to simplify setup with mysql/apache
* pull in new look and feel
* add django tests to validate all artifacts - if we say they can download it and it appears on a page anywhere, it should have a test
* improve docs of code on wiki. We have a nice start (ty E & M); I'd like to improve it.
** events - more info and list types supported
** what logic is in jscript , what is in python
** database schema definition and description esp interrelationships.
** list django tests, mostly so we can see what we are missing.
* build mode triggerred off of database entry, not autonomous process.
* add asynchronicity. I have noted a number of places where commands result in a sluggish ui. I'm nervous about this one.
** for example, starting a build that requires us to clone layers has a noticeable delay as compared to starting a local only project build.
* verify we can stop builds cleanly.
* get the rest of our logs into our local toaster dir
* allow us to run and stop 2 toasters on the same machine without them interfering with each other
* (2.2 or later for sure) discuss how to support multiple back end bb servers.
** probably will need to be able to add servers/remove servers/see server status/build state
* be able to see more details about build. For example, see the "jobs" being processed like you can in knotty
* revisit what variables we let people change. sstate_dir and dl_dir should certainly be allowed to change
* discuss way we do migrations. possibly change. thoughts:
** only support migrations from last release to current. (e.g. if you were running toaster jethro you could update to jethro++, but could not from fido to jethro)
** take migration from the startup script. it's only for releasetorelease.
*** allow it to be in for master and ease of development w/in a release and pull at end as we do with moving releases.
** whatever we decide, add a test set for it so we know it works
* Be able to delete things from the ui
** old builds
** old projects
** imported layers we no longer want
* Be able to set from the ui a policy to delete all builds/recipes/packages that are older than XXX &/or be able to set maximum size on db and delete everything older than XXX when we near that size
* update the builds on the web page so we dont have to hit refresh to see the build progress.

==== Elliot's ====

* Make sure all files lint properly
* Include lint in CI builds
* Improve test coverage of all areas of the UI and back-end
* Clean up toasterui.py so it's easier to see what's going on in there
* Fix localhostbecontroller so it doesn't rely on what's in the log file when figuring out whether the bitbake server has started
* Provide a way to modify settings in settings.py without editing that file (e.g. with a local overlay configuration file)
* Move the logic, environment variables, directory setup and script calls from bin/toaster into Django commands: this would allow you to run toaster correctly, with all the required setup, without having to use bin/toaster; it would also mean that we could provide cleaner production setup instructions, as a user could run a series of Django commands (with their own parameters) to setup their environment; bin/toaster would then just execute a series of Django commands

==== Belén's ====

* Finish image customisation. Related bugs: 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Review interaction with layers: as it is, imposes heavy restrictions on users. Some of the questions I would like to consider:
** Should the import layer action be global instead of per project, so that you can reuse imported layers across projects?
** Should we allow users to override the release layer branch, setting a particular layer index layer to a different branch or commit?
** Should we allow users to set a different git repo for layer index layers?
** Should we allow users to override the bitbake revision set by the release in a project?
** Related bugs: 6640, 6701, 7574, 8426, 8429
* Access control (a simple one to start, with very basic permissions). Related bugs: 6233, 6234
* WIC integration (getting a step closer to the holy grail of 'click button' > 'image deployed in board')
* Fix the variable history (this is one of the features users have highly praised, and it is a bit broken in 2.0). Related bugs: 5811, 8488, 8190, 8189, 8188
* Get Toaster to collect build data from Jenkins builds. Once again, repeatedly requested by users. Related bugs: 7527

==== Ed's ====

* Merge analysis and managed modes
* Fix as much pending bugs as possible.
* Finish image customisation.
* Increase test coverage. It would be good to set realistic goals, e.g. cover specific modules or increase coverage to 10% and follow the plan.
* Include production configuration into testing
* Cover views.py with tests and split it into modules. Currently it's huge and hard to maintain. I suspect there are a lot of unused APIs in there.
* Finish refactoring of buildcontroller code. This work is started in ed/toaster/bec and sitting there for quite long time.
* Bring patchset support to toaster patchwork.
* Add 'submitted upstream' and 'merged upstream' statuses to patchwork. Make the statuses updated automatically when patch is accepted to toaster-next or bitbake master.
* Clean up the code. Set realistic goals for pylint scores and follow them.
* Enhance Jenkins CI jobs to run all possible django, tts and pylint tests

== All bugs for 2.1+ ==

{{#bugzilla:
|columns=id,milestone,summary,status,priority
|milestone=future,2.1,2.1 M1,2.1 M2,2.1 M3,2.1 M4
|sort=priority
|product=Toaster
|status=!resolved
}}

[https://bugzilla.yoctoproject.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ACCEPTED&bug_status=IN%20PROGRESS%20DESIGN&bug_status=IN%20PROGRESS%20DESIGN%20COMPLETE&bug_status=IN%20PROGRESS%20IMPLEMENTATION&bug_status=IN%20PROGRESS%20REVIEW&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&columnlist=product%2Cbug_status%2Cshort_desc%2Cchangeddate%2Ctarget_milestone&component=toaster&f1=target_milestone&list_id=476868&o1=greaterthan&product=Toaster&query_format=advanced&resolution=---&v1=2.0&query_based_on= Bugzilla query]

Toaster future release planning

2015-10-23T16:53:38Z

Ed: /* Ed's */

[[Category:Toaster]]

== 2.1 Planning ==

=== Wish lists ===

==== Michael's ====
* Finish image-customisation 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Remove pseudo API cruft / template context to json response stuff
* Consolidate used API into it's own view
* Finish toaster tables porting
* Get selenium test wrapper
* Create a toasterclient.py to interact with toaster to avoid need for 'command line builds'
** This would use toaster's API as the entry point to using bitbake
** It could be called by CI systems
** It could be used by auto builders etc
** Means that there are no two modes anywhere in Toaster
** Allows project configuration to be changed in toaster from the command line

==== Brian's ====
This is *not* ordered! This is more of a brain dump :)
* Collapse analysis and managed mode
* Working CI for each commit into toaster-next as well as for project peoples testME branches on poky-contrib:
** run django tests
** run selenium tests
** leverage sstate to make runs generally shorter
* remove git assumptions from code
* rationalize/simplify the configuration scripts
* if bitbake-memres comes out, interact with it gracefully (this is my preferred method of collapsing analysis and managed)
* fix the tmpdir/release build issue &/or discuss the need to support building old releases with a UI rather than limiting toaster to build the release it is part of. This is inherently fragile.
* ask bb to parse any layer added to a project and such as imported layers, and layers specified in the configuration file to give us recipe information.
* improve our build event following:
** note parse events
** update/retrieve ui so that we can tell something is happening before the first build event comes
** eliminate the remaining random tracebacks from try/except failures.
* allow configuration in addition to the addition/removal of layers/packages
** kernel config
* add user control/authentication
* update to Django 1.8. Always stay on Django LTS versions
* add layer update from layers.openembedded.org to the UI
* add Django tests for building e.g. we should be able to build core-image-sato from a django test and validate the db
* add mysql script to simplify setup with mysql/apache
* pull in new look and feel
* add django tests to validate all artifacts - if we say they can download it and it appears on a page anywhere, it should have a test
* improve docs of code on wiki. We have a nice start (ty E & M); I'd like to improve it.
** events - more info and list types supported
** what logic is in jscript , what is in python
** database schema definition and description esp interrelationships.
** list django tests, mostly so we can see what we are missing.
* build mode triggerred off of database entry, not autonomous process.
* add asynchronicity. I have noted a number of places where commands result in a sluggish ui. I'm nervous about this one.
** for example, starting a build that requires us to clone layers has a noticeable delay as compared to starting a local only project build.
* verify we can stop builds cleanly.
* get the rest of our logs into our local toaster dir
* allow us to run and stop 2 toasters on the same machine without them interfering with each other
* (2.2 or later for sure) discuss how to support multiple back end bb servers.
** probably will need to be able to add servers/remove servers/see server status/build state
* be able to see more details about build. For example, see the "jobs" being processed like you can in knotty
* revisit what variables we let people change. sstate_dir and dl_dir should certainly be allowed to change
* discuss way we do migrations. possibly change. thoughts:
** only support migrations from last release to current. (e.g. if you were running toaster jethro you could update to jethro++, but could not from fido to jethro)
** take migration from the startup script. it's only for releasetorelease.
*** allow it to be in for master and ease of development w/in a release and pull at end as we do with moving releases.
** whatever we decide, add a test set for it so we know it works
* Be able to delete things from the ui
** old builds
** old projects
** imported layers we no longer want
* Be able to set from the ui a policy to delete all builds/recipes/packages that are older than XXX &/or be able to set maximum size on db and delete everything older than XXX when we near that size
* update the builds on the web page so we dont have to hit refresh to see the build progress.

==== Elliot's ====

* Make sure all files lint properly
* Include lint in CI builds
* Improve test coverage of all areas of the UI and back-end
* Clean up toasterui.py so it's easier to see what's going on in there
* Fix localhostbecontroller so it doesn't rely on what's in the log file when figuring out whether the bitbake server has started
* Provide a way to modify settings in settings.py without editing that file (e.g. with a local overlay configuration file)
* Move the logic, environment variables, directory setup and script calls from bin/toaster into Django commands: this would allow you to run toaster correctly, with all the required setup, without having to use bin/toaster; it would also mean that we could provide cleaner production setup instructions, as a user could run a series of Django commands (with their own parameters) to setup their environment; bin/toaster would then just execute a series of Django commands

==== Belén's ====

* Finish image customisation. Related bugs: 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Review interaction with layers: as it is, imposes heavy restrictions on users. Some of the questions I would like to consider:
** Should the import layer action be global instead of per project, so that you can reuse imported layers across projects?
** Should we allow users to override the release layer branch, setting a particular layer index layer to a different branch or commit?
** Should we allow users to set a different git repo for layer index layers?
** Should we allow users to override the bitbake revision set by the release in a project?
** Related bugs: 6640, 6701, 7574, 8426, 8429
* Access control (a simple one to start, with very basic permissions). Related bugs: 6233, 6234
* WIC integration (getting a step closer to the holy grail of 'click button' > 'image deployed in board')
* Fix the variable history (this is one of the features users have highly praised, and it is a bit broken in 2.0). Related bugs: 5811, 8488, 8190, 8189, 8188
* Get Toaster to collect build data from Jenkins builds. Once again, repeatedly requested by users. Related bugs: 7527

==== Ed's ====

* Merge analysis and managed modes
* Fix as much pending bugs as possible.
* Finish image customisation.
* Increase test coverage. It would be good to set realistic goals, e.g. cover specific modules or increase coverage to 10% and follow the plan.
* Include production configuration into testing
* Cover views.py with tests and split it into modules. Currently it's huge and hard to maintain. I suspect there are a lot of unused APIs in there.
* Finish refactoring of buildcontroller code. This work is started in ed/toaster/bec and sitting there for quite long time.
* Bring patchset support to toaster patchwork.
* Add 'submitted upstream' and 'merged upstream' statuses to patchwork. make the statuses change automatically when patch is accepted to toaster-next or bitbake master.
* Clean up the code. Set realistic goals for pylint scores and follow them.
* Enhance Jenkins CI jobs to run all possible django, tts and pylint tests

== All bugs for 2.1+ ==

{{#bugzilla:
|columns=id,milestone,summary,status,priority
|milestone=future,2.1,2.1 M1,2.1 M2,2.1 M3,2.1 M4
|sort=priority
|product=Toaster
|status=!resolved
}}

[https://bugzilla.yoctoproject.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ACCEPTED&bug_status=IN%20PROGRESS%20DESIGN&bug_status=IN%20PROGRESS%20DESIGN%20COMPLETE&bug_status=IN%20PROGRESS%20IMPLEMENTATION&bug_status=IN%20PROGRESS%20REVIEW&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&columnlist=product%2Cbug_status%2Cshort_desc%2Cchangeddate%2Ctarget_milestone&component=toaster&f1=target_milestone&list_id=476868&o1=greaterthan&product=Toaster&query_format=advanced&resolution=---&v1=2.0&query_based_on= Bugzilla query]

Toaster future release planning

2015-10-23T16:51:39Z

Ed: /* Ed's */

[[Category:Toaster]]

== 2.1 Planning ==

=== Wish lists ===

==== Michael's ====
* Finish image-customisation 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Remove pseudo API cruft / template context to json response stuff
* Consolidate used API into it's own view
* Finish toaster tables porting
* Get selenium test wrapper
* Create a toasterclient.py to interact with toaster to avoid need for 'command line builds'
** This would use toaster's API as the entry point to using bitbake
** It could be called by CI systems
** It could be used by auto builders etc
** Means that there are no two modes anywhere in Toaster
** Allows project configuration to be changed in toaster from the command line

==== Brian's ====
This is *not* ordered! This is more of a brain dump :)
* Collapse analysis and managed mode
* Working CI for each commit into toaster-next as well as for project peoples testME branches on poky-contrib:
** run django tests
** run selenium tests
** leverage sstate to make runs generally shorter
* remove git assumptions from code
* rationalize/simplify the configuration scripts
* if bitbake-memres comes out, interact with it gracefully (this is my preferred method of collapsing analysis and managed)
* fix the tmpdir/release build issue &/or discuss the need to support building old releases with a UI rather than limiting toaster to build the release it is part of. This is inherently fragile.
* ask bb to parse any layer added to a project and such as imported layers, and layers specified in the configuration file to give us recipe information.
* improve our build event following:
** note parse events
** update/retrieve ui so that we can tell something is happening before the first build event comes
** eliminate the remaining random tracebacks from try/except failures.
* allow configuration in addition to the addition/removal of layers/packages
** kernel config
* add user control/authentication
* update to Django 1.8. Always stay on Django LTS versions
* add layer update from layers.openembedded.org to the UI
* add Django tests for building e.g. we should be able to build core-image-sato from a django test and validate the db
* add mysql script to simplify setup with mysql/apache
* pull in new look and feel
* add django tests to validate all artifacts - if we say they can download it and it appears on a page anywhere, it should have a test
* improve docs of code on wiki. We have a nice start (ty E & M); I'd like to improve it.
** events - more info and list types supported
** what logic is in jscript , what is in python
** database schema definition and description esp interrelationships.
** list django tests, mostly so we can see what we are missing.
* build mode triggerred off of database entry, not autonomous process.
* add asynchronicity. I have noted a number of places where commands result in a sluggish ui. I'm nervous about this one.
** for example, starting a build that requires us to clone layers has a noticeable delay as compared to starting a local only project build.
* verify we can stop builds cleanly.
* get the rest of our logs into our local toaster dir
* allow us to run and stop 2 toasters on the same machine without them interfering with each other
* (2.2 or later for sure) discuss how to support multiple back end bb servers.
** probably will need to be able to add servers/remove servers/see server status/build state
* be able to see more details about build. For example, see the "jobs" being processed like you can in knotty
* revisit what variables we let people change. sstate_dir and dl_dir should certainly be allowed to change
* discuss way we do migrations. possibly change. thoughts:
** only support migrations from last release to current. (e.g. if you were running toaster jethro you could update to jethro++, but could not from fido to jethro)
** take migration from the startup script. it's only for releasetorelease.
*** allow it to be in for master and ease of development w/in a release and pull at end as we do with moving releases.
** whatever we decide, add a test set for it so we know it works
* Be able to delete things from the ui
** old builds
** old projects
** imported layers we no longer want
* Be able to set from the ui a policy to delete all builds/recipes/packages that are older than XXX &/or be able to set maximum size on db and delete everything older than XXX when we near that size
* update the builds on the web page so we dont have to hit refresh to see the build progress.

==== Elliot's ====

* Make sure all files lint properly
* Include lint in CI builds
* Improve test coverage of all areas of the UI and back-end
* Clean up toasterui.py so it's easier to see what's going on in there
* Fix localhostbecontroller so it doesn't rely on what's in the log file when figuring out whether the bitbake server has started
* Provide a way to modify settings in settings.py without editing that file (e.g. with a local overlay configuration file)
* Move the logic, environment variables, directory setup and script calls from bin/toaster into Django commands: this would allow you to run toaster correctly, with all the required setup, without having to use bin/toaster; it would also mean that we could provide cleaner production setup instructions, as a user could run a series of Django commands (with their own parameters) to setup their environment; bin/toaster would then just execute a series of Django commands

==== Belén's ====

* Finish image customisation. Related bugs: 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Review interaction with layers: as it is, imposes heavy restrictions on users. Some of the questions I would like to consider:
** Should the import layer action be global instead of per project, so that you can reuse imported layers across projects?
** Should we allow users to override the release layer branch, setting a particular layer index layer to a different branch or commit?
** Should we allow users to set a different git repo for layer index layers?
** Should we allow users to override the bitbake revision set by the release in a project?
** Related bugs: 6640, 6701, 7574, 8426, 8429
* Access control (a simple one to start, with very basic permissions). Related bugs: 6233, 6234
* WIC integration (getting a step closer to the holy grail of 'click button' > 'image deployed in board')
* Fix the variable history (this is one of the features users have highly praised, and it is a bit broken in 2.0). Related bugs: 5811, 8488, 8190, 8189, 8188
* Get Toaster to collect build data from Jenkins builds. Once again, repeatedly requested by users. Related bugs: 7527

==== Ed's ====

* Merge analysis and managed modes
* Fix as much peding bugs as possible.
* Finish image customisation.
* Increase test coverage. It would be good to set realistic goals, e.g. cover specific modules or increase coverage to 10% and follow the plan.
* Include production configuration into testing
* Cover views.py with tests and split it into modules. Currently it's huge and hard to maintain. I suspect there are a lot of unused APIs in there.
* Finish refactoring of buildcontroller code. This work is started in ed/toaster/bec and sitting there for quite long time.
* Bring patchset support to toaster patchwork.
* Add 'submitted upstream' and 'merged upstream' statuses to patchwork. make the statuses change automatically when patch is accepted to toaster-next or bitbake master.
* Clean up the code. Set realistic goals for pylint scores and follow them.
* Enhance Jenkins CI jobs to run all possible django, tts and pylint tests

== All bugs for 2.1+ ==

{{#bugzilla:
|columns=id,milestone,summary,status,priority
|milestone=future,2.1,2.1 M1,2.1 M2,2.1 M3,2.1 M4
|sort=priority
|product=Toaster
|status=!resolved
}}

[https://bugzilla.yoctoproject.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ACCEPTED&bug_status=IN%20PROGRESS%20DESIGN&bug_status=IN%20PROGRESS%20DESIGN%20COMPLETE&bug_status=IN%20PROGRESS%20IMPLEMENTATION&bug_status=IN%20PROGRESS%20REVIEW&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&columnlist=product%2Cbug_status%2Cshort_desc%2Cchangeddate%2Ctarget_milestone&component=toaster&f1=target_milestone&list_id=476868&o1=greaterthan&product=Toaster&query_format=advanced&resolution=---&v1=2.0&query_based_on= Bugzilla query]

Toaster future release planning

2015-10-23T16:42:43Z

Ed: /* 2.1 Planning */

[[Category:Toaster]]

== 2.1 Planning ==

=== Wish lists ===

==== Michael's ====
* Finish image-customisation 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Remove pseudo API cruft / template context to json response stuff
* Consolidate used API into it's own view
* Finish toaster tables porting
* Get selenium test wrapper
* Create a toasterclient.py to interact with toaster to avoid need for 'command line builds'
** This would use toaster's API as the entry point to using bitbake
** It could be called by CI systems
** It could be used by auto builders etc
** Means that there are no two modes anywhere in Toaster
** Allows project configuration to be changed in toaster from the command line

==== Brian's ====
This is *not* ordered! This is more of a brain dump :)
* Collapse analysis and managed mode
* Working CI for each commit into toaster-next as well as for project peoples testME branches on poky-contrib:
** run django tests
** run selenium tests
** leverage sstate to make runs generally shorter
* remove git assumptions from code
* rationalize/simplify the configuration scripts
* if bitbake-memres comes out, interact with it gracefully (this is my preferred method of collapsing analysis and managed)
* fix the tmpdir/release build issue &/or discuss the need to support building old releases with a UI rather than limiting toaster to build the release it is part of. This is inherently fragile.
* ask bb to parse any layer added to a project and such as imported layers, and layers specified in the configuration file to give us recipe information.
* improve our build event following:
** note parse events
** update/retrieve ui so that we can tell something is happening before the first build event comes
** eliminate the remaining random tracebacks from try/except failures.
* allow configuration in addition to the addition/removal of layers/packages
** kernel config
* add user control/authentication
* update to Django 1.8. Always stay on Django LTS versions
* add layer update from layers.openembedded.org to the UI
* add Django tests for building e.g. we should be able to build core-image-sato from a django test and validate the db
* add mysql script to simplify setup with mysql/apache
* pull in new look and feel
* add django tests to validate all artifacts - if we say they can download it and it appears on a page anywhere, it should have a test
* improve docs of code on wiki. We have a nice start (ty E & M); I'd like to improve it.
** events - more info and list types supported
** what logic is in jscript , what is in python
** database schema definition and description esp interrelationships.
** list django tests, mostly so we can see what we are missing.
* build mode triggerred off of database entry, not autonomous process.
* add asynchronicity. I have noted a number of places where commands result in a sluggish ui. I'm nervous about this one.
** for example, starting a build that requires us to clone layers has a noticeable delay as compared to starting a local only project build.
* verify we can stop builds cleanly.
* get the rest of our logs into our local toaster dir
* allow us to run and stop 2 toasters on the same machine without them interfering with each other
* (2.2 or later for sure) discuss how to support multiple back end bb servers.
** probably will need to be able to add servers/remove servers/see server status/build state
* be able to see more details about build. For example, see the "jobs" being processed like you can in knotty
* revisit what variables we let people change. sstate_dir and dl_dir should certainly be allowed to change
* discuss way we do migrations. possibly change. thoughts:
** only support migrations from last release to current. (e.g. if you were running toaster jethro you could update to jethro++, but could not from fido to jethro)
** take migration from the startup script. it's only for releasetorelease.
*** allow it to be in for master and ease of development w/in a release and pull at end as we do with moving releases.
** whatever we decide, add a test set for it so we know it works
* Be able to delete things from the ui
** old builds
** old projects
** imported layers we no longer want
* Be able to set from the ui a policy to delete all builds/recipes/packages that are older than XXX &/or be able to set maximum size on db and delete everything older than XXX when we near that size
* update the builds on the web page so we dont have to hit refresh to see the build progress.

==== Elliot's ====

* Make sure all files lint properly
* Include lint in CI builds
* Improve test coverage of all areas of the UI and back-end
* Clean up toasterui.py so it's easier to see what's going on in there
* Fix localhostbecontroller so it doesn't rely on what's in the log file when figuring out whether the bitbake server has started
* Provide a way to modify settings in settings.py without editing that file (e.g. with a local overlay configuration file)
* Move the logic, environment variables, directory setup and script calls from bin/toaster into Django commands: this would allow you to run toaster correctly, with all the required setup, without having to use bin/toaster; it would also mean that we could provide cleaner production setup instructions, as a user could run a series of Django commands (with their own parameters) to setup their environment; bin/toaster would then just execute a series of Django commands

==== Belén's ====

* Finish image customisation. Related bugs: 8070, 8081, 8082, 8103, 8104, 8117, 8128, 8132, 8091
* Review interaction with layers: as it is, imposes heavy restrictions on users. Some of the questions I would like to consider:
** Should the import layer action be global instead of per project, so that you can reuse imported layers across projects?
** Should we allow users to override the release layer branch, setting a particular layer index layer to a different branch or commit?
** Should we allow users to set a different git repo for layer index layers?
** Should we allow users to override the bitbake revision set by the release in a project?
** Related bugs: 6640, 6701, 7574, 8426, 8429
* Access control (a simple one to start, with very basic permissions). Related bugs: 6233, 6234
* WIC integration (getting a step closer to the holy grail of 'click button' > 'image deployed in board')
* Fix the variable history (this is one of the features users have highly praised, and it is a bit broken in 2.0). Related bugs: 5811, 8488, 8190, 8189, 8188
* Get Toaster to collect build data from Jenkins builds. Once again, repeatedly requested by users. Related bugs: 7527

==== Ed's ====

* Fix as much peding bugs as possible.
* Finish image customisation.
* Increase test coverage. It would be good to set realistic goals, e.g. cover specific modules or increase coverage to 10% and follow the plan.
* Include production configuration into testing
* Cover views.py with tests and split it into modules. Currently it's huge and hard to maintain. I suspect there are a lot of unused APIs in there.
* Finish refactoring of buildcontroller code. This work is started in ed/toaster/bec and sitting there for quite long time.
* Bring patchset support to toaster patchwork.
* Add 'submitted upstream' and 'merged upstream' statuses to patchwork. make the statuses change automatically when patch is accepted to toaster-next or bitbake master.
* Clean up the code. Set realistic goals for pylint scores and follow them.
* Enhance Jenkins CI jobs to run all possible django, tts and pylint tests

== All bugs for 2.1+ ==

{{#bugzilla:
|columns=id,milestone,summary,status,priority
|milestone=future,2.1,2.1 M1,2.1 M2,2.1 M3,2.1 M4
|sort=priority
|product=Toaster
|status=!resolved
}}

[https://bugzilla.yoctoproject.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ACCEPTED&bug_status=IN%20PROGRESS%20DESIGN&bug_status=IN%20PROGRESS%20DESIGN%20COMPLETE&bug_status=IN%20PROGRESS%20IMPLEMENTATION&bug_status=IN%20PROGRESS%20REVIEW&bug_status=REOPENED&bug_status=NEEDINFO&bug_status=WaitForUpstream&columnlist=product%2Cbug_status%2Cshort_desc%2Cchangeddate%2Ctarget_milestone&component=toaster&f1=target_milestone&list_id=476868&o1=greaterthan&product=Toaster&query_format=advanced&resolution=---&v1=2.0&query_based_on= Bugzilla query]