rel_v0_0_8-b1 for example.
- newt's built in package manager knows to fetch packages from that
git branch (we make the changes to newt once we branch.)
May be an issue with this (I think not 100% sure), does that imply that
a release can basically change over time? Or that it would be
downloading un-released software?
I misspoke, it's probably a tag not a branch. I guess somebody could
always move a tag, but somebody can always replace a tarball too.
I'm pretty flexible about how we push this out -- feedback and thoughts
are really welcome. Let me give some quick technical background for the
uninitiated.
<way too long explanation>
newt is the build and package management tool that pulls the various
components of our OS together and generates builds. A collection of
eggs (packages), forms a nest. And newt knows how to build all the eggs
in a nest. "Larva" is our default nest, with a collection of eggs.
In newt, you can generate what is called a clutch. A clutch is a
snapshot of the eggs in a given nest at a given point in time. As an
example, here is the start of a clutch file generated on git master larva:
$ newt nest generate-clutch larva http://mynewt.apache.org
name: larva
url: http://mynewt.apache.org
eggs:
project/test:
vers: 0.1.0
hash: 8de883b9aa460677bb79da3c495fc654186b017e
deps:
- fs/nffs@none#stable
- libs/testutil@none#stable
- libs/os@none#stable
- libs/bootutil@none#stable
- libs/testreport@none#stable
hw/bsp/stm32f3discovery:
vers: 0.0.0
hash: 73f2aa944dec135e07891f4f0a1e154858b99024
deps:
- hw/mcu/stm/stm32f3xx@none#stable
project/blinky:
<snip>
A user can configure newt to look at remote clutch files (HTTP or GIT),
and newt will go read those files and install them in the user's local
nest (along with resolving any dependencies.)
The idea is that the core of Mynewt will mature in the ASF, and people
will get the default set of packages from there, and those packages will
track along with overall project maturity (e.g. they'll be stable
someday :-)
However, around this core, hopefully people will be adding all sorts of
cool things around Mynewt. These could be either Apache sub-projects
(ala Hadoop ecosystem), corporations who share code across projects or
just some guy who happened to put a cool library on Github. Each of
these would generate and distribute their own clutch-file, which the
newt tool can be pointed at.
</way too long explanation>
For something to be a release it must be voted on and while in
incubation also voted on by the incubator PMC. So as long at that git
branch only contained approved software that would be fine.
Agree.
- We build newt for all supported platforms (Linux, Mac OS X, Windows)
-- and we distribute that, along with necessary LICENSE files on our
website.
Best to distribute via the apache mirrors, there a cgi script you can
use to grab the artefacts from the nearest mirror. Not there must needs
to be a source only release and an optional binary convenience release.
Agree. We'll need some help with this once we've got the tarballs.
- Those eggs then come with individual LICENSE files, which have their
license info.
Yep the LICENSE (and NOTICE) files need to reflect only what is bundled
in the artefact downloaded.
They are Apache -- can you point me to the specific files you're
referencing so I can double check?
./hw/bsp/nrf51dk/include/bsp/cmsis_nvic.h
./hw/bsp/nrf52pdk/include/bsp/cmsis_nvic.h
./hw/bsp/olimex_stm32-e407_devboard/include/bsp/cmsis_nvic.h
./hw/bsp/stm32f3discovery/include/bsp/cmsis_nvic.h
./libs/cmsis-core/src/cmsis_nvic.c
Thanks I'll dig into these & report back.
Anyhow, here is the FatFs license, it is liberal
Yep no issue there.
We can raise this with legal, alternatively we could move the MCU &
BSP definitions to github. People would need to config newt to point
at the github URL (newt add-clutch), but it would get around ASF
license issues.
Only if it’s considered an optional dependancy, but I think that is the
case. i.e. It not required for newt/larva to work. We had similar issue
with Adobe licensed software and Apache Flex.
It is an optional dependency. These files are board support headers and
drivers for the STM32F3Discovery board. We'll have support for Nordic,
Arduino, other STMicro boards in the default release - it would be just
this board that was banished to Github. Plus, it will be fun to test
out if our clutch system actually works :-)
Sterling
