Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Christopher Collins]

On Fri, Feb 19, 2016 at 06:18:19PM +1100, Justin Mclean wrote:
> HI,
> 
> > Since we won't be releasing binaries this time around, the only
> > artifacts are: 1) the source tgz files
> 
> Perhaps a silly question. But how are those tgz files generated?

Oh, I see.  No, not silly at all.  I used the following command to create
the tgz files (executed from the repository base directory):

git archive --format tgz --output ~/tmp/rel/bin/larva/larva-0.8.0-b1.tgz 
--prefix larva-0.8.0-b1/ mynewt_0_8_0_b1_tag

With the obvious substitutions for tadpole and newt.

Chris

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Justin Mclean]

HI,

> Since we won't be releasing binaries this time around, the only
> artifacts are: 1) the source tgz files

Perhaps a silly question. But how are those tgz files generated?

Thanks,
Justin

LICENSE and NOTICE contents / headers

[Justin Mclean]

Hi,

I’m not 100% sure what’s in the release files but from a quick look (rushing 
out t the door) I’m guessing it still needs a tiny bit of work:

Newt repo still has:
./.git/hooks/pre-rebase.sample

And a number of files (mostly .go files) still have "Copyright 2015 Runtime 
Inc.”

Larval has a number of files with copyright that is this presumably licensed 
under something, for example:
Copyright (C) 2004  Kustaa Nyholm
Copyright (C) 2010  CJlano
Copyright (C) 2011  Petteri Aimonen
Copyright (c) 2004,2012 Kustaa Nyholm / SpareTimeLabs
Copyright (c) 2007, 2008, 2009, 2010 Dado Sutter and Bogdan Marinescu
Copyright (c) 2007, 2008, 2009, 2010, 2011 Dado Sutter and Bogdan Marinescu
Copyright (c) 2012 Petteri Aimonen 
Copyright (c) 2015, Nordic Semiconductor ASA

See my previous email of this for all the licenses and files.

As does tadpole, for instance:
 * Copyright (c) 1982, 1986, 1988, 1991, 1993
 * Copyright (c) 1991, 1993
 * Copyright (c) 1995-2001 Kungliga Tekniska Högskolan
 * Copyright (c) 1999-2009 KEIL, 2009-2013 ARM Germany GmbH
# Copyright (c) 2006, 2008 Junio C Hamano

Again see my previous email of this for all the licenses.

Thanks,
Justin

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Christopher Collins]

On Fri, Feb 19, 2016 at 06:05:20PM +1100, Justin Mclean wrote:
> What the process for generating the release artefacts?

Since we won't be releasing binaries this time around, the only
artifacts are: 1) the source tgz files, 2) the ascii signature files,
and 3) the SHA checksums.

Or maybe you are asking about the binaries which contain LGPL code?  My
apologies if I misunderstood the question.

Chris

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Christopher Collins]

On Fri, Feb 19, 2016 at 05:54:11PM +1100, Justin Mclean wrote:
> Hi,
> 
> >> Would you like me to give the various LICENSE and NOTICE files a once
> >> over before you make an official RC?
> > 
> > Oops, I am not sure how I missed this.  Yes, that would be extremely
> > helpful.
> 
> I assume they are in the top of each repo? I can’t get to this right now 
> (just about to go out to dinner on friday) but can look at it tomorrow.

Yes, that is correct.  Thanks, that would be great.

Chris

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Justin Mclean]

Hi,

>> Would you like me to give the various LICENSE and NOTICE files a once
>> over before you make an official RC?
> 
> Oops, I am not sure how I missed this.  Yes, that would be extremely
> helpful.

I assume they are in the top of each repo? I can’t get to this right now (just 
about to go out to dinner on friday) but can look at it tomorrow.

Thanks,
Justin

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Justin Mclean]

Hi,

Another thought - releasing all 3 products make sense for the first release. 

After that you may want to consider releasing and voting on each one separately 
- less to review / less moving pieces to foul up :-)

Thanks,
Justin

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Christopher Collins]

On Fri, Feb 19, 2016 at 04:19:57PM +1100, Justin Mclean wrote:
> Would you like me to give the various LICENSE and NOTICE files a once
> over before you make an official RC?

Oops, I am not sure how I missed this.  Yes, that would be extremely
helpful.

Thanks,
Chris

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Justin Mclean]

Hi,

> No - the binaries certainly *do* contain LGPL code.  I take it that is a
> problem :).  I think we can refrain from releasing the binaries until we
> get the LGPL issue sorted out.  If others disagree with this, please
> chime in.

Having a source only release would make it easier. Just be aware that you can’t 
host the binaries at Apache unless they are not voted on.

Thanks,
Justin

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Christopher Collins]

On Fri, Feb 19, 2016 at 04:19:57PM +1100, Justin Mclean wrote:

[convenience binaries]
> And are we 100% sure that they don’t contain the LGPL code (source or
> compiled) ?

No - the binaries certainly *do* contain LGPL code.  I take it that is a
problem :).  I think we can refrain from releasing the binaries until we
get the LGPL issue sorted out.  If others disagree with this, please
chime in.

> >
> > http://mail-archives.apache.org/mod_mbox/incubator-myriad-dev/201511.mbox/%3CCAGim3%2B2fFCE4LC7HpNPtg5r7_01sFzkfLsyGaLvXcV%2B6f-_CRg%40mail.gmail.com%3E
> >  
> > 
> 
> It’s good, but I add the git hash, tags can be deleted or changed. The
> idea is that given a successful vote someone could take the info in
> the email and produce the exact same release as you did. You may also
> offer some advice on what is needed to be checked when voting.
> 
> It also customary to send out a [DISCUSS] email as well that was the
> vote thread doesn’t get polluted by people replying with questions /
> any issues they have found..

All good points.  Noted.

Thanks,
Chris

Re: hal organization and multiple smaller packages

[Sterling Hughes]

Paul -

I think you make a number of good points here, but I'm not sure all of 
them argue for re-organizing the HAL, but perhaps just improving the 
existing structure.


The purpose of the HAL is to abstract MCU peripheral functions, and make 
that portable across various MCU architectures.  This is why the HAL 
APIs are defined in the hw/hal package, but the implementation for the 
HAL lives in the various mcu support packages in hw/mcu (*).


I think it makes sense to group the definition of MCU support functions 
together.  That way, as people use it, and contribute support back -- 
support for a given processor grows in a cohesive fashion.  Now, of course:


- Not all MCUs will implement all HAL interfaces (e.g. DMA v non-DMA chips)
- Not all HAL implementations are going to be complete: if I don't use 
the ADC on a chip, am I going to spend my time developing a MCU support 
package for it?


I think, however, that this can be exposed both:

- At runtime, with HAL introspection APIs
- At package/compile time, using capabilities (MCU packages export more 
fine grained hal capabilities, e.g. hal-adc, hal-adc-outc)


That way people who are searching for MCU support packages, can inspect 
what aspects of the HAL are/aren't implemented (view capabilities.)


I think then, on top of the HAL there can be more complex drivers for 
everything you want to do with it.  As an example, hal-gpio would just 
have on/off, and read state (abstracting peripherals): but you might 
distribute a gpio-led package on top of that, which had common functions 
for controlling LEDs through GPIO (PWM for color, etc.) This driver 
would require that their be a hal-gpio capability present, but it 
wouldn't need to specify the specific support package necessary.


Fundamentally, I think the question comes down to me: where do you want 
the implementation of MCU specific functionality to live.  Ideally MCU 
support is in a single package/set of packages in hw/mcu that is being 
constantly improved for all peripheral interfaces.  The HAL then becomes 
a glue to let all the higher layer drivers operate, without knowing 
about the specifics of the underlying MCU implementation.


Thoughts?

Sterling

(*) hw/hal does take some definitions from the BSP.  I'm more inclined 
to move these out of the HAL, and have the HAL just be MCU support.  But 
that is a discussion for another day.



On 2/18/16 4:32 PM, p...@wrada.com wrote:


Just wanted to pass on some thoughts I had today about the hal ...

I was thinking about how much is in a hal, how it will grow over time and how to tell 
"how complete" a given hal is.  And more importantly how to provide simple 
stuff that does basic HW (like polling GPIO) while allowing advanced features of chips 
that support it.

Let's consider one example: ADC.

For now assume that the customer wants a simple way to poll ADC.  So they go to newt and 
look at possible packages with "*adc*".

The find

Libs/poll_adc
Libs/adc_periodic
Libs/adc_compare
And perhaps some custom ADC libraries that are not hardware agnostic written by 
HW vendors that want to provide the best interfaces to their products (open 
source is great)

Which is my trying to say that there is different functionality that they may 
want from adc and generally folks don't want to learn anything more than they 
have to especially with these frameworky things that are already hard to get 
your head around.

The chose the simple one since they are not ready to do anything fancy and just 
want to see it working.  And add it to their project.yml file.

Now lets consider their Hardware platform they have.  Suppose the customer has 
the following different combinations of hardware

   1.  A board with an MCU with ADC channels built into the MCU
   2.  A board with an MCU with no ADC channels
   3.  A board with an external SPI ADC device (possibly to replace the 
internal ADC that was not accurate enough).

They include libs/poll_adc into their project ...  if it were me I'd want the 
dependency system to say that "unresolved dependency, libs/poll_adc requires a 
driver that implements hw/simple_adc_driver.  The following packages implement 
hw/simple_adc_driver:

  *   samd21/adc
  *   nr52/adc
  *   ..
  *   sim/adc
  *   stub/adc
  *   mcp3008/adc (This is an external SPI ADC)

The customer now knows what is available or what they need to write.  This may 
be an important step.  For example suppose they have both #1 and #3 and have 
internal and external ADC for different purposes (not accurate enough etc).  
How to they select that they are binding the ADC to #3 or #1.  Or do they get 
to?  Do we need to make sure its their choice, but we give them enough guidance 
to make it easy? What if the customer wants both an internal and external ADC 
through our simple API?

They just chose the one for their internal ADC and move on.  Now they build and 
get some unresolved external

Unersolved reference to 

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Christopher Collins]

On Fri, Feb 19, 2016 at 01:43:59PM +1100, Justin Mclean wrote:
> If you’re going to be RM, you should sign up to that list and/or take
> a look previous incubating release votes so you know what to expect.

Good idea.  I have subscribed to that list.

Now... :) I am afraid I'm going to have to nag you with a few more
questions.  If you could take a look when you have a second, that would
be really helpful.  Thanks for your patience!

(1)
I was a little confused about where I should put the release artifacts
prior to sending the dev vote email.  After some reading, I have
inferred that I should put the artifacts here via svn:

https://dist.apache.org/repos/dist/dev/incubator/mynewt

Is that correct?

(2)
Below is a list of files I am planning on uploading to the server:

/repos/dist/dev/incubator/mynewt/mynewt-0.8.0-b1-incubating/
larva-0.8.0-b1.tgz  # Larva source
larva-0.8.0-b1.tgz.asc  # Larva ASCII armored detached signature
larva-0.8.0-b1.tgz.sha  # Larva SHA512 checksum

newt-0.8.0-b1.tgz   # Newt
newt-0.8.0-b1.tgz.asc
newt-0.8.0-b1.tgz.sha

tadpole-0.8.0-b1.tgz# Tadpole
tadpole-0.8.0-b1.tgz.asc
tadpole-0.8.0-b1.tgz.sha

newt-bin-linux-0.8.0-b1.tgz # Newt binary for linux
newt-bin-linux-0.8.0-b1.tgz.asc
newt-bin-linux-0.8.0-b1.tgz.sha

newt-bin-osx-0.8.0-b1.tgz   # Newt binary for Mac OS X
newt-bin-osx-0.8.0-b1.tgz.asc
newt-bin-osx-0.8.0-b1.tgz.sha

/repos/dist/dev/incubator/mynewt/
KEYS# Public keys for sig. validation

The binary files are created from the newt sources as a convenience to
the user.

Does the above directory tree look reasonable to you?

(3) I was planning on using this message as a template for the vote email
that I will send to the mynewt dev list.  Do you think it is suitable?


http://mail-archives.apache.org/mod_mbox/incubator-myriad-dev/201511.mbox/%3CCAGim3%2B2fFCE4LC7HpNPtg5r7_01sFzkfLsyGaLvXcV%2B6f-_CRg%40mail.gmail.com%3E

Thanks,
Chris

[BLE] Questions about BLE on Apache Mynewt

[Huynh Minh Quang]

Dear Sir/Madam,
First, I see that Apache Mynewt is the excellent RTOS and I would like 
to use Apache Mynewt for my BLE module using Nordict NRF51822 IC (this 
already working with mbed contribution). So, I wonder where can I find 
the documentation, user manual, tool-chain, complier or something like 
that to developer my module with Mynewt. Can you help me to figure out 
what I have to do?

Sorry about my languages, I'm not an native speaker.

Thanks and best regards,
Quang Huynh Minh

Re: incubator-mynewt-newt git commit: LICENSE, NOTICE, and KEYS files for newt.

[Christopher Collins]

On Fri, Feb 19, 2016 at 01:18:19PM +1100, Justin Mclean wrote:
> Hi,
> 
> > Thanks, Justin.  If we remove this from the distribution (i.e., don't
> > bundle it), do we still need to mention it in LICENSE or NOTICE?
> 
> No only things that are bundled need to be mentioned in LICENSE and
> NOTICE, so no mention in notice.

Got it.  Thanks.

> 
> But having a dependancy on lGPL / GPL gives restrictions that are not
> compatible with the Apache license so mention at in the README and
> that it will be fixed in a future release.
> 
> I seen the send button a little to quick last email. Want me to do
> what sebb suggests and email legal / Jim.

Ah, I see the post
(http://mail-archives.apache.org/mod_mbox/incubator-general/201602.mbox/browser).
My reading of that message was that Sam (sebb?) had already sent a note
to legal, but maybe he is waiting for someone to protest :).  Either
way, it would probably be a good idea (and much appreciated!) if you
sent a note as well, or please feel free to let me know if there is
anything I can do.

Thanks again,
Chris

hal organization and multiple smaller packages

[p...@wrada.com]

Just wanted to pass on some thoughts I had today about the hal ...

I was thinking about how much is in a hal, how it will grow over time and how 
to tell "how complete" a given hal is.  And more importantly how to provide 
simple stuff that does basic HW (like polling GPIO) while allowing advanced 
features of chips that support it.

Let's consider one example: ADC.

For now assume that the customer wants a simple way to poll ADC.  So they go to 
newt and look at possible packages with "*adc*".

The find

Libs/poll_adc
Libs/adc_periodic
Libs/adc_compare
And perhaps some custom ADC libraries that are not hardware agnostic written by 
HW vendors that want to provide the best interfaces to their products (open 
source is great)

Which is my trying to say that there is different functionality that they may 
want from adc and generally folks don't want to learn anything more than they 
have to especially with these frameworky things that are already hard to get 
your head around.

The chose the simple one since they are not ready to do anything fancy and just 
want to see it working.  And add it to their project.yml file.

Now lets consider their Hardware platform they have.  Suppose the customer has 
the following different combinations of hardware

  1.  A board with an MCU with ADC channels built into the MCU
  2.  A board with an MCU with no ADC channels
  3.  A board with an external SPI ADC device (possibly to replace the internal 
ADC that was not accurate enough).

They include libs/poll_adc into their project ...  if it were me I'd want the 
dependency system to say that "unresolved dependency, libs/poll_adc requires a 
driver that implements hw/simple_adc_driver.  The following packages implement 
hw/simple_adc_driver:

 *   samd21/adc
 *   nr52/adc
 *   ..
 *   sim/adc
 *   stub/adc
 *   mcp3008/adc (This is an external SPI ADC)

The customer now knows what is available or what they need to write.  This may 
be an important step.  For example suppose they have both #1 and #3 and have 
internal and external ADC for different purposes (not accurate enough etc).  
How to they select that they are binding the ADC to #3 or #1.  Or do they get 
to?  Do we need to make sure its their choice, but we give them enough guidance 
to make it easy? What if the customer wants both an internal and external ADC 
through our simple API?

They just chose the one for their internal ADC and move on.  Now they build and 
get some unresolved external

Unersolved reference to bspProvideADCConfig()

They gather that they need to provide the info in this function and go fill it 
out. This seemingly would have a different API for every device since the 
different devices might have the need for different settings.  For example, the 
external one might be looking for a spi port while the internal ones may be 
looking for pins.   The sim version might be looking for a function pointer 
that for a function that returns a fake A/D sample.

Either way they implement this using the prototype in the adc package they 
selected and they are off and running.  Done...

They might have the same experience for ADC, DAC, SPI, GPIO, PWM, I2C, CAN, 
ZIGBEE, WIFI, Bluetooth, etc.  I would think we would want all of these 
peripheral components to work the same way.  Given that, maybe the hal should 
be reserved for OS critical functions only and the rest should be libraries.

Comments from folks.  Do you think that this is too complicate.  Do we want to 
ensure that chip vendors making spi components can write drivers for mynewt 
that have a dependency on an MCU SPI port without knowing which SPI port 
implementation they are using. In other words, they provide hw/simple_adc and 
that depends on hw/spi .

Just food for thought. Not sure whether this is doable or even worth it, just 
trying to imagine when all hardware vendors just write a mynewt driver for 
their sensor, MCU, etc as standard practice to sell them. Want to make sure 
that is possible, easy and flexible enough to support non MCU parts.

Re: Kicking off a release

[Justin Mclean]

Hi,

> Good question: I nominate Chris.

Well as long as Chris want to take on that role that’s fine :-)

Here’s some links on the process / publishing a release:
http://www.apache.org/dev/release.html 
http://www.apache.org/dev/release-publishing.html 

http://incubator.apache.org/guides/releasemanagement.html 


> Nice.  So Chris (or whoever) needs to create all the release artifacts 
> (source tarball, binaries, etc.) and tag the tree.  Compose an email to dev@ 
> first (with a [VOTE] thread?), and then if that passes, compose a similar 
> email to general@, with the note that it has already passed a release vote 
> within the podling, correct?

Yep.  This is the check list for voting on a release [1], as we’re in 
incubation it’s not expected to be 100% perfect.

Re voting only PPMC votes are binding and you need three +1 votes and more +1 
than -1s. [2] (A -1 votes isn’t a veto.)

Thanks,
Justin

1. http://incubator.apache.org/guides/releasemanagement.html#check-list
2. http://www.apache.org/foundation/voting.html#ReleaseVotes

Re: Kicking off a release

[Christopher Collins]

Sounds good.  I will act as the release manager.

Chris

On Thu, Feb 18, 2016 at 01:48:43PM -0800, Sterling Hughes wrote:
> 
> 
> On 2/16/16 5:07 PM, Justin Mclean wrote:
> > Hi,
> >
> > Who is going to act as release manager?
> >
> 
> Good question: I nominate Chris.
> 
> >
> >> - Add release notes to the mynewt distribution
> >> - Tag the tree with a B1 release tag (mynewt_0_8_0_b1_tag)
> >> - Start a [VOTE] thread to [VOTE] on the Mynewt release (along with
> >> the given tag)
> >> - Should that [VOTE] go through, that tag can then be built into a
> >> series of release artifacts
> >
> > The release artefacts are built first. The  [VOTE] email will have links
> > to the source tar (and binary if we’re creating them) to vote on.
> >
> > After the vote here, you then need to put it up for vote on the
> > incubator general mailing list were only incubator PMC votes are
> > binding. A few of the mentors are IPMC (myself included) so that should
> > help.
> >
> 
> 
> Nice.  So Chris (or whoever) needs to create all the release artifacts 
> (source tarball, binaries, etc.) and tag the tree.  Compose an email to 
> dev@ first (with a [VOTE] thread?), and then if that passes, compose a 
> similar email to general@, with the note that it has already passed a 
> release vote within the podling, correct?
> 
> > Only after both votes pass can you do this:
> >> - That can then be posted on the Mynewt website, along with release notes.
> >
> > And send out a release announcemt!
> >
> > The LICENSE and NOTICE files also need to be updated [1] before a VOTE
> > can be called.
> >
> > Also last time I looked 2 or 3 repos still have a few header files and
> > the like to clean up. It would probably pass an incubator vote in that
> > state (given there a JIRA to fix it) but best to clean up before release
> > I think?
> >
> 
> I'll run through and make changes today.
> 
> Thanks,
> Sterling

Re: Kicking off a release

[Sterling Hughes]

On 2/16/16 5:07 PM, Justin Mclean wrote:

Hi,

Who is going to act as release manager?



Good question: I nominate Chris.




- Add release notes to the mynewt distribution
- Tag the tree with a B1 release tag (mynewt_0_8_0_b1_tag)
- Start a [VOTE] thread to [VOTE] on the Mynewt release (along with
the given tag)
- Should that [VOTE] go through, that tag can then be built into a
series of release artifacts


The release artefacts are built first. The  [VOTE] email will have links
to the source tar (and binary if we’re creating them) to vote on.

After the vote here, you then need to put it up for vote on the
incubator general mailing list were only incubator PMC votes are
binding. A few of the mentors are IPMC (myself included) so that should
help.




Nice.  So Chris (or whoever) needs to create all the release artifacts 
(source tarball, binaries, etc.) and tag the tree.  Compose an email to 
dev@ first (with a [VOTE] thread?), and then if that passes, compose a 
similar email to general@, with the note that it has already passed a 
release vote within the podling, correct?



Only after both votes pass can you do this:

- That can then be posted on the Mynewt website, along with release notes.


And send out a release announcemt!

The LICENSE and NOTICE files also need to be updated [1] before a VOTE
can be called.

Also last time I looked 2 or 3 repos still have a few header files and
the like to clean up. It would probably pass an incubator vote in that
state (given there a JIRA to fix it) but best to clean up before release
I think?



I'll run through and make changes today.

Thanks,
Sterling