Meeting #227
Updated by André Neto over 9 years ago
h1. Sprint planning
*Date of the meeting:* 08/09/2015
*Sprint objective:* Fifth release of MARTe aimed at defining the introspection base infrastructure. Refactoring of folders and namespacing to also be included.
*Backlog items:* #169, #188, #197, #226, #225
h1. Sprint review
The following issues and concerns were discussed by the team during the sprint:
* How to improve code documentation. Find the balance between cost and sufficient quality.
** Use StaticList as a template?
* How to simplify test documentation.
** Use StaticListTest as a template?
* Rename namespace to marte (as opposed to MARTe)
* Discuss the using namespace directive.
* Discuss if a glossary of acronyms is needed.
* Discuss if namespace sections (i.e. between brackets) must or not span over section comments.
* Discuss use of latex syntax for formulas on documentation (if agree, then discuss which rendering engine must be used)
h1. Sprint retrospective
* Things that the team should start doing
# The QA reviewer shall verify if the documentation is sufficiently detailed to understand the scope of the class/function under scrutiny.
## "StaticList":https://vcis-gitlab.f4e.europa.eu/aneto/MARTe2/blob/3e7f7a73634da5a58528392a55939e30d4a86265/Source/Core/BareMetal/L1Portability/StaticList.h can be used as a best-practice template, particularly for the end-user classes (e.g. GAMs).
## For the tests the same simplified strategy used in "StaticListTest":https://vcis-gitlab.f4e.europa.eu/aneto/MARTe2/blob/3e7f7a73634da5a58528392a55939e30d4a86265/Test/Core/BareMetal/L1Portability/StaticListTest.h shall be used.
# The lint comments in the code shall include the MISRA violated rule(s) with the format @/*lint -e{...,...,...} [...,...,...] comment*/@, e..g. @/*lint -e{123, 678} [3-1-1,5-2-1] this operation is guaranteed to be safe in this context*/@.
# The use of defensive programming shall be maximised (both by verifying and asserting unexpected parameters and by propagating errors (e.g. returning false)). In particular NULL arguments shall be checked and asserted.
# The namespace name MARTe shall continue to be used. TODO
* Things that the team should stop doing
# The using namespace directive shall not be used in the tests.
# The namespace usage in the header files shall be broken between and after the inline method definition, i.e.:
<pre><code>
/*---------------------------------------------------------------------------*/
/* Class declaration */
/*---------------------------------------------------------------------------*/
namespace MARTe{
...
}
/*---------------------------------------------------------------------------*/
/* Inline method definitions */
/*---------------------------------------------------------------------------*/
namespace MARTe{
...
}
</code></pre> TODO
* Things that the team should continue doing
# Diving large user-stories in sub-branches (as done for #225). TODO
h1. Technical debt
#169, #188 TODO
h1. Backlog review (restimation, reprioritization, weighting)
TODO
*Date of the meeting:* 08/09/2015
*Sprint objective:* Fifth release of MARTe aimed at defining the introspection base infrastructure. Refactoring of folders and namespacing to also be included.
*Backlog items:* #169, #188, #197, #226, #225
h1. Sprint review
The following issues and concerns were discussed by the team during the sprint:
* How to improve code documentation. Find the balance between cost and sufficient quality.
** Use StaticList as a template?
* How to simplify test documentation.
** Use StaticListTest as a template?
* Rename namespace to marte (as opposed to MARTe)
* Discuss the using namespace directive.
* Discuss if a glossary of acronyms is needed.
* Discuss if namespace sections (i.e. between brackets) must or not span over section comments.
* Discuss use of latex syntax for formulas on documentation (if agree, then discuss which rendering engine must be used)
h1. Sprint retrospective
* Things that the team should start doing
# The QA reviewer shall verify if the documentation is sufficiently detailed to understand the scope of the class/function under scrutiny.
## "StaticList":https://vcis-gitlab.f4e.europa.eu/aneto/MARTe2/blob/3e7f7a73634da5a58528392a55939e30d4a86265/Source/Core/BareMetal/L1Portability/StaticList.h can be used as a best-practice template, particularly for the end-user classes (e.g. GAMs).
## For the tests the same simplified strategy used in "StaticListTest":https://vcis-gitlab.f4e.europa.eu/aneto/MARTe2/blob/3e7f7a73634da5a58528392a55939e30d4a86265/Test/Core/BareMetal/L1Portability/StaticListTest.h shall be used.
# The lint comments in the code shall include the MISRA violated rule(s) with the format @/*lint -e{...,...,...} [...,...,...] comment*/@, e..g. @/*lint -e{123, 678} [3-1-1,5-2-1] this operation is guaranteed to be safe in this context*/@.
# The use of defensive programming shall be maximised (both by verifying and asserting unexpected parameters and by propagating errors (e.g. returning false)). In particular NULL arguments shall be checked and asserted.
# The namespace name MARTe shall continue to be used. TODO
* Things that the team should stop doing
# The using namespace directive shall not be used in the tests.
# The namespace usage in the header files shall be broken between and after the inline method definition, i.e.:
<pre><code>
/*---------------------------------------------------------------------------*/
/* Class declaration */
/*---------------------------------------------------------------------------*/
namespace MARTe{
...
}
/*---------------------------------------------------------------------------*/
/* Inline method definitions */
/*---------------------------------------------------------------------------*/
namespace MARTe{
...
}
</code></pre> TODO
* Things that the team should continue doing
# Diving large user-stories in sub-branches (as done for #225). TODO
h1. Technical debt
#169, #188 TODO
h1. Backlog review (restimation, reprioritization, weighting)
TODO