incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sterling Hughes <>
Subject Re: [DISCUSS] Mynewt Incubation Proposal
Date Tue, 06 Oct 2015 17:13:07 GMT
>> We have two types of regression tests currently implemented:
>> - "Native": Simulated on Linux and Mac OS X.  We compile the OS &
>> libraries with 32-bit GCC, and then use setjmp() and longjmp() to save
>> and restore our task stacks, and signals to provide a timing interval.
>> Every egg (package) has unit tests that run in this simulated
>> environment, and per-egg unit tests can be run natively on your PC.
>> - "Project": The per-package regression tests can be combined into a
>> build project designed to test them for a specific platform (e.g.
>> olimex-stm32-e407.)  The project defines what packages to include, and
>> what tests to run.  This produces an ELF file that can be loaded on
>> the native platform, and the tests will spit their results to the
>> local FS on that platform.
> How much hardware are you going to end up needing to do this?

For the simulated package regression tests it should be very light.
It's bare C, the only "expensive" (from a system perspective) element
is the timer, which we ask for a 1ms tick.  However, this is a virtual
timer (1ms of scheduled run-time, not a hard 1ms), so it should scale
fine with system load.

For the automatic hardware loading and regression tests, there is a
physical element to it.  We'll host that here at runtime on behalf of
the project to start, and then as we grow, we can re-evaluate (for
example, if a big co with lots of space joined the project, we'd
happily migrate to their facility. :-)   We don't yet have the ability
to do this though, so its speculative at the moment.

>> Prior to release, we'll have to decide whether we want to start with
>> just a single big package repository or break it up into smaller
>> multiple nests.  I imagine we'll start with one big one, and then as
>> the code base grows, tease out the package repositories into distinct
>> sets of functionality (that probably makes sense to test together as
>> well.)
> I suppose my curiosity is exactly that. Most linux distros tend to
> have repo per package, though they migrated to that from a SVN tree.

Indeed.  We started out with git subtrees and one repo per-package,
and it was an unholy nightmare.

We modified the package manager so it can pull packages directly from
a remote nest, removing the need to unbundle them first.  This allows
us to have a single git repo for all the packages.  So I imagine over
time this we'll organize it into a set of nests, that contain "groups"
of packages that want to be together.  So bluetooth connected devices
might have their own nest, and industrial devices might have their own
nest.  But I think that's 12-mos down the road, at least.  For now,
having everything in a single nest makes it easy to evolve and test
the code together, and doesn't give us a significant drawback in terms
of maintainability.  Users can just pull the packages they want from
the nest.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message