On 03/31/2017 09:52 PM, Gedare Bloom wrote:
Don't forget the deadline is Monday to submit your Final
PDF and proof of enrollment. The "Final" PDF can be submitted multiple
times, so go ahead and submit it when you finish a first draft. Add
your draft proposal to the tracking table at
https://devel.rtems.org/wiki/GSoC/2017 also, to get some possible
feedback.
Thanks for the welcome! (I realize I am late to the GSOC application table).
I'm set on improving code coverage of the testsuite, but I found some
questions as I'm starting to look into how its done.
The link on the wiki to the current code status is currently broken
<https://www.rtems.org/ftp/pub/rtems/people/joel/coverage/>, so I tried
to generate a sample coverage report for 4.12 using ./do_coverage,
./run_coverage and ./coverage_cron as suggested on the wiki here
<https://devel.rtems.org/wiki/TBR/UserManual/RTEMS_Coverage_Analysis#HowitisDoneNow>but
without any luck. Is there an up to date coverage report available?
I modified the VERSIONS-COVERAGE file like the wiki said, and once that
didn't work dug around in the script but fix it myself quickly.
Could updating these coverage analysis scripts be a viable component of
a GSOC proposal?
In addition, I'd like to actually make some improvements the code
coverage itself.
The most recent information I could find was these bar graphs from 2009.
<https://devel.rtems.org/wiki/Developer/Coverage/Status>
If these graphs reflect the current coverage state, I think that
improving coverage for the i386/pc386,
would be interesting because there is room for improvement in both the
Baseline and Developmental groups (if these coverage statistics are up
to date).
Does anyone know of a good reason to choose another BSP over i386/pc386?
I've just posted a draft of my proposal to the GSOC page.
If there's any feedback I'll be sure to update my proposal in time.
-Andy MacGregor
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
