Some thoughts (belatedly): * I dont think we need coredump in B1. * Do we need a different BLE MCU/transceiver for first release? Not sure if we should spend time on the stack as opposed to diverting it to porting to a different MCU/transceiver. * Do we need separate host/controller for first release?
> On Feb 1, 2016, at 8:23 AM, Sterling Hughes <sterl...@apache.org> wrote: > > Hiya, > > I think we're getting close to ready for our first beta release. If you can > bear with the long email, please read and give feedback. > > (MENTORS: this would be a good one to review) > > In my mind, the release schedule looks like: > > - Feb 12th, B1 > - March 12th, B2 > - April 12th, Release X > > Where X is something like 0.8 or 0.9 -- I don't think we're quite at a 1.0 > yet, but we're definitely well beyond a 0.1 release. > > In my mind, remaining for a B1 release is: > > - ASF copyright headers: we've been lax in updating these, most of which say > (c) Runtime, licensed under Apache 2. These need to be changed to the > standard Apache project headers. > > - Log & Statistics cleanup: I've done most of the infrastructure, but we need > to count statistics and use our logging infrastructure throughout the code. > > - Project cleanup: Blinky & Slinky are our two main projects (Blinky is the > basic setup, and Slinky is a more full-featured example.) > > - Coredumps? Do we need these in B1? > > - Release packaging: how is Mynewt distributed? Do we branch the larva > repository, and distribute newt binaries that pull from a specific branch of > ASF infrastructure? Do we package up all of larva to begin with? > > - JIRA: We need to get our bugs & features into JIRA, along with links to > JIRA from the Mynewt website. > > Between B1 & B2, I suspect the majority of our efforts are going to be > focused on: > > - Testing & Docs: The unit test framework has been unevenly used throughout > the various packages. We'll need to spend some significant time updating and > adding unit & regression tests. > > I'd say the docs as-is need a fair hand on them from all the developers as > well. Aditi has done a great job getting the infrastructure up, but one > person cannot document the entire thing! > > - Board Ports: In order to increase adoption we're going to need a variety of > board ports, along two vectors: > a- Maker/Common Boards: the OS should run on the boards a developer or > hobbyist is likely to have on them. This means Arduino, etc. > b- Diversity of BLE chipsets: Right now Nordic NRF52 and shortly NRF51 are > supported. We're going to need to expand this beyond Nordic in the first > release. > > - HAL interfaces: we're missing some crucial ones ATM (e.g. SPI), and this > will need to get a little better. > > - Continued BLE development: > - While we've got a compliant implementation now, we're going to need to > further develop things like BLE security, etc. > > Finally, between B2 and Release, I think we're going to be looking at: > > - Bugfixing & Documentation > > - Some assorted board ports, if low risk. > > - More regression testing. > > Thanks, > > Sterling
