On 7/01/2014 12:18 pm, Joel Sherrill wrote:
On 1/6/2014 5:14 PM, Chris Johns wrote:
On 7/01/2014 4:24 am, Joel Sherrill wrote:
On 1/6/2014 11:13 AM, Philipp Eppelt wrote:
Where are we on this?
I think I was OK on it. If Gedare is also, then it should be merged.
How will this change be tested on a regular basis ? As we move to
constant integration testing we need a way to test this code.
Philipp.. can you provide us a "test plan"? That is, how you build and
test today
for what you have. I know that it is likely only a couple of tests at
this point
from an RTEMS perspective.
I would like to understand how this extra dependency is tested and
managed on an on going basis before getting my support.
Agreed. We need to be conscious of this.
Is a test plan sufficient? We don't have the infrastructure currently to
automate
testing this. I really hope Philipp enjoyed the project and will stay
involved and help
us grow this.
Currently I do not know what I would need to run "Pok", can I build it
from source and what is needed to do this ? Does Pok itself need special
tools ?
What development hosts does Pok support ?
If RTEMS is to offer a Pok based solution the project needs to address
all these factors.
This is an important capability for the growth of RTEMS as a project.
We
need to
lay the groundwork so we can eventually test Pok, help it grow, and ensure
its stability. In a perfect world, it would have good test results
before we test
Pok+RTEMS and put it through our acceptance tests.
I was not wishing to address acceptance tests. I am currently only
concerned with patches entering RTEMS and knowing this code is being
tested. As we move to constant integration we need to make sure the Pok
component is maintained or we risk it rotting. I would rather have the
commitment to support it addressed up front. I have no idea what this is.
Chris
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
