Moving towards a beta release

[Sterling Hughes <st...@apache.org>]

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

Re: Moving towards a beta release

[will sanfilippo <wi...@runtime.io>]

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 <st...@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

Re: Moving towards a beta release

[Justin Mclean <ju...@classsoftware.com>]

HI,

> In my mind, the release schedule looks like:
> - Feb 12th, B1
> - March 12th, B2
> - April 12th, Release X

On other projects I’ve worked on having a set release schedules was seen as a bit a hinderance for volunteers to contribute. It may also take some time and a few release candidates before a release is approved. But each project is different and up to you how you want do this.

> - ASF copyright headers: we've been lax in updating these

Would be required to pass a vote on the incubator so that’s a given :-)

> - Release packaging: how is Mynewt distributed?

Apache make source releases that are distributed via it’s mirrors. [1][2] You can also provide convenience binary releases. Perhaps aim for a source only release the first time around and then add convenience binary release in a later release?

>  Do we branch the larva repository, and distribute newt binaries that pull from a specific branch of ASF infrastructure?

The release must be able to be recreated so the usual practice to make a release branch. The release vote will include the tag/hash of the software voted on. Apache distributes sources not binaries, but you can provide them as well for users convenience. [3][4]

> - JIRA: We need to get our bugs & features into JIRA, along with links to JIRA from the Mynewt website.

I’d suggest make a JIRA with sub tasks for the release. Here’s an example [5]

Thanks,
Justin

1. http://incubator.apache.org/guides/releasemanagement.html#glossary-incubator-dist
2. https://www.apache.org/mirrors/
3. http://incubator.apache.org/guides/releasemanagement.html#notes-on-source-only-releases
4. http://incubator.apache.org/guides/releasemanagement.html#notes-on-binary-only-releases
5. https://issues.apache.org/jira/browse/FLEX-34955