Re: [VOTE] Release Mynewt 0.8.0-b1-incubating

[Justin Mclean]

Hi,

> These are actually generated using sha512:
> 
> gpg2 --print-md SHA512 larva-0.8.0-b1.tgz > larva-0.8.0-b1.tgz.sha

Ah it's sha512. Looks like openssl is a bit more friendly:
openssl dgst -sha512 larva-0.8.0-b1.tgz
SHA512(larva-0.8.0-b1.tgz)= 
51915329ee9e17f87517c2b61c99268b9aaa478d2c85aa0bb036276d4b980a119be18deb471e762aa80cb4d57478390e60a0eae10481f7235ffe83a86990d700

It's the signing that’s more important. I’ve seem release without sha hashes.

Thanks,
Justin

Re: [3/3] incubator-mynewt-larva git commit: Add license to .gitignore file.

[Justin Mclean]

Hi,

> I'll second that: Justin, and I say this knowing you're Australian: you've 
> earned as many beers as you can drink when we meet :-)

I certainly drink beer. However I’ll pass on Fosters and Budwizer - they are 
not release quality IMO :-)

Thanks,
Justin

Re: [VOTE] Release Mynewt 0.8.0-b1-incubating

[Justin Mclean]

Hi,

Sorry but it’s -1 (binding) from me.

To be clear that doesn’t stop other people voting +1, and if you get 3+1 you 
can still put it up on the IPMC general list for a vote. You’re also welcome to 
try and change my mind, anyone can change their vote after initial voting. All 
the -1 means is I wouldn’t release it, but what makes a release good enough 
quality to release is going to vary form person to person an that’s all OK.

I would however expect that in the currently form it may not pass an IPMC vote. 
It’s very close however and there only a couple of missing things.

I checked:
- release artefacts are missing incubating from their names [1][2]
- signatures OK but not sure re hashes
- missing DISCLAIMER in release artefacts [3]
- LICENSE(s) all good
- NOTICE good but missing original developer (runtime)
- newt doesn’t have a REAME at the top level
- no unexpected binary files in the releases
- all Apache source file have Apache headers / no double headers I could find
- not sure how to compile the source repos - some instruction on this in the 
releases would be nice

How were the hashes generated?

I’m seeing this:
$ openssl sha1 larva-0.8.0-b1.tgz
SHA1(larva-0.8.0-b1.tgz)= 99b15843d0a5af3f3d7dbdcb52afb80144ee1255
$ cat larva-0.8.0-b1.tgz.sha
/Users/ccollins/tmp/rel/bin/larva-0.8.0-b1.tgz: 
51915329 EE9E17F8 7517C2B6 1C99268B 9AAA478D 2C85AA0B B036276D 4B980A11 9BE18DEB
 471E762A A80CB4D5 7478390E 60A0EAE1 0481F723 5FFE83A8 6990D700

You probably want to remove "/Users/ccollins/tmp/rel/bin/larva-0.8.0-b1.tgz:” 
from that file.

Some possible improvements:
- Re naming it's a good idea to add apache to the name as well as I believe it 
gives some extra legal protection / shows it’s an apache product.
- It a good idea to sign the artefacts with an apache email address.

Thanks,
Justin

1. http://incubator.apache.org/guides/releasemanagement.html#naming
2. http://incubator.apache.org/incubation/Incubation_Policy.html#Releases (note 
the word MUST)
3. http://incubator.apache.org/guides/releasemanagement.html#check-list

Re: [DISCUSS] Release Mynewt 0.8.0-b1-incubating

[Justin Mclean]

Hi,

Part of the requirement for voting on a source artefact is that you can compile 
the package. With the current source releases how is that actually done?

Thanks,
Justin

Re: [DISCUSS] Release Mynewt 0.8.0-b1-incubating

[Justin Mclean]

Hi,

See we already have  an enthusiastic +1 vote. It is customary to list what was 
actually checked in the release and on what platform it was tested on. 

Being the first release I do suggest we double check everything just in case 
something has slipped through the cracks, other wise the vote may not pass on 
the incubator list and we’ll have to do it all again.

See here for what to check [1]

Thanks,
Justin

1. http://incubator.apache.org/guides/releasemanagement.html#check-list

Fwd: hal organization and multiple smaller packages

[will sanfilippo]

Sorry all; thought this was addressed to dev

> Begin forwarded message:
> 
> From: will sanfilippo 
> Subject: Re: hal organization and multiple smaller packages
> Date: February 22, 2016 at 3:42:15 PM PST
> To: sterl...@apache.org
> 
> See comments
> 
>> On Feb 22, 2016, at 2:58 PM, Sterling Hughes  wrote:
>> 
>> 
>> 
>> On 2/22/16 1:24 PM, will sanfilippo wrote:
>>> My 1/2 cent on this topic (and I certainly dont think you killed the 
>>> discussion; it is a difficult topic):
>>> 
>>> * I think the HAL is meant to be a fairly general, simple, abstraction. 
>>> Hopefully over time we will be able to incorporate more advanced HAL 
>>> features, but most HALs I have seen implement the basics and I bet that 
>>> works for most folks.
>>> * I think the HAL should live in hw/mcu. Well, api in hw/hal and 
>>> implementation in hw/mcu.
>>> * As sterling says, drivers can be built that use the HAL. Take the 
>>> external ADC example. There would be a driver for that ADC chip that would 
>>> use a SPI HAL if it had SPI. For internal ADCs, the HAL provided in hw/hal 
>>> should be enough as I suspect it will (eventually), implement what most 
>>> folks want.
>>> * As far as being able to see what features of a HAL are implemented, I 
>>> dont see why this is such a problem but it is probably because I am not 
>>> thinking of “beginner” users. Doesnt seem terribly difficult to document, 
>>> on a per mcu basis, which features of the HAL are supported by that 
>>> particular MCU. And if the developer calls an API with some parameters that 
>>> are not implemented on this MCU they get an error. Part of the problem I 
>>> have with this is is my own personal bias: I would never blindly call HAL 
>>> functions without first reading the chip documentation. I dont see why 
>>> anyone would do such a thing :-)
>>> * I am not a fan of runtime HAL introspection APIs. To me, that is just 
>>> extra code that serves very little useful purpose.
>> 
>> I agree with no runtime, but think there should be capabilities on a more 
>> granular basis.
> 
> Sorry, I did not mean to imply that there should not be more granular 
> capabilites. I think there should be. Having ways to insect packages for 
> these capabilities so developers can easily see what our HAL supports is a 
> good idea. I just dont think this needs to be made overly complicated is all.
> 
>> 
>> i.e. a driver can require a hal-adc, or hal-gpio capability, and an MCU can 
>> export these, rather than the just "hal."
>> 
>>> * I think the HALs should allow for the user to choose which “peripheral” 
>>> to bind to and that is done through the BSP or the HAL API itself. For 
>>> example, the user should be able to pick ADC #1 or ADC #3.
>>> * I do agree that sometimes it is difficult to know that you need to call 
>>> functions like bspProvideADCconfig() and the like. Not sure how this gets 
>>> solved other than documentation and looking at examples that we provide.
>>> 
>> 
>> IMO, the HAL should provide APIs to do this, and the BSP should call those 
>> APIs.
> Not sure what you mean exactly. Is it the same as our current structure? The 
> project code calls hal api which in turn call bsp api?
> 
>> Did you see other email: what do you think about flash?  Should the HAL APIs 
>> just apply to internal flash / should we get rid of HAL Flash altogether, or 
>> should HAL flash encompass both internal & external flashes...?
>> 
>> Sterling
> I did :-) I have not given it enough thought so I dont think I have an 
> intelligent answer. However, the idea of a HAL flash appeals to me. Question: 
> if we said the hal flash should be internal only, how do we deal with 
> external flashes? Library code calls driver code?

Re: [3/3] incubator-mynewt-larva git commit: Add license to .gitignore file.

[Christopher Collins]

On Tue, Feb 23, 2016 at 09:39:41AM +1100, Justin Mclean wrote:
> Hi,
> 
> > Whoops, thanks Justin.  I didn't see that note in time. 
> 
> Pulling license header of files that may not require it is a non issue, I 
> very much doubt that anyone would take issue with it or in fact even notice 
> :-)
> 
> > Is there anything else you can think of that I might have missed?
> 
> AFAICS it all looks good.

At the risk of exceeding my 'thank you' quota, thanks again for your
patience and support.  I am sure the process will be a little less
painful next time :).

Chris

[VOTE] Release Mynewt 0.8.0-b1-incubating

[Christopher Collins]

Hello all,

I am pleased to be calling this vote for the source release of
mynewt-0.8.0-b1-incubating.

Apache Mynewt is a community-driven, permissively licensed open source
initiative for constrained, embedded applications.

The release candidate to be voted on is available at:

https://dist.apache.org/repos/dist/dev/incubator/mynewt/mynewt-0.8.0-b1-incubating/

The commits under consideration are as follows:

larva:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-larva
commit: bd2db03ccbd019a20267459bf46ae1e1428f1f46

tadpole:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-tadpole
commit: b00813ec355a0bc3681c232503aab92ea9157fa9

newt:
repos: https://git-wip-us.apache.org/repos/asf/incubator-mynewt-newt
commit: 27a92e159926778f24d19b0795307a34e05ec8ed

The release candidate is signed with a GPG key available at:

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

The vote is open for at least 72 hours and passes if a majority of at least
three +1 PPMC votes are cast.

[ ] +1 Release this package
[ ]  0 I don't feel strongly about it, but don't object
[ ] -1 Do not release this package because...

Anyone can participate in testing and voting, not just committers, please feel
free to try out the release candidate and provide your votes.

A separate [DISCUSS] thread will be opened to talk about this release
candidate.

Thanks,
Chris

Re: hal organization and multiple smaller packages

[Sterling Hughes]

On 2/22/16 1:24 PM, will sanfilippo wrote:

My 1/2 cent on this topic (and I certainly dont think you killed the 
discussion; it is a difficult topic):

* I think the HAL is meant to be a fairly general, simple, abstraction. 
Hopefully over time we will be able to incorporate more advanced HAL features, 
but most HALs I have seen implement the basics and I bet that works for most 
folks.
* I think the HAL should live in hw/mcu. Well, api in hw/hal and implementation 
in hw/mcu.
* As sterling says, drivers can be built that use the HAL. Take the external 
ADC example. There would be a driver for that ADC chip that would use a SPI HAL 
if it had SPI. For internal ADCs, the HAL provided in hw/hal should be enough 
as I suspect it will (eventually), implement what most folks want.
* As far as being able to see what features of a HAL are implemented, I dont 
see why this is such a problem but it is probably because I am not thinking of 
“beginner” users. Doesnt seem terribly difficult to document, on a per mcu 
basis, which features of the HAL are supported by that particular MCU. And if 
the developer calls an API with some parameters that are not implemented on 
this MCU they get an error. Part of the problem I have with this is is my own 
personal bias: I would never blindly call HAL functions without first reading 
the chip documentation. I dont see why anyone would do such a thing :-)
* I am not a fan of runtime HAL introspection APIs. To me, that is just extra 
code that serves very little useful purpose.


I agree with no runtime, but think there should be capabilities on a 
more granular basis.


i.e. a driver can require a hal-adc, or hal-gpio capability, and an MCU 
can export these, rather than the just "hal."



* I think the HALs should allow for the user to choose which “peripheral” to 
bind to and that is done through the BSP or the HAL API itself. For example, 
the user should be able to pick ADC #1 or ADC #3.
* I do agree that sometimes it is difficult to know that you need to call 
functions like bspProvideADCconfig() and the like. Not sure how this gets 
solved other than documentation and looking at examples that we provide.



IMO, the HAL should provide APIs to do this, and the BSP should call 
those APIs.


Did you see other email: what do you think about flash?  Should the HAL 
APIs just apply to internal flash / should we get rid of HAL Flash 
altogether, or should HAL flash encompass both internal & external 
flashes...?


Sterling

Re: [3/3] incubator-mynewt-larva git commit: Add license to .gitignore file.

[Justin Mclean]

Hi,

Again no harm done but no required.  JFYI - Files without any creative content 
don’t need a license header, .gitignore would fall under that. [1]

Justin

1. http://www.apache.org/legal/src-headers.html#faq-exceptions

Re: Planning to add log facilities

[Sterling Hughes]

Welcome Gordon!

That would be awesome.

Sterling

On 2/22/16 3:37 AM, Gordon Chaffee wrote:

Hi, I'm new to the list, and I'm working on some code to extend the
existing logs capabilities. Specifically, I'm planning to add the following:

newtmgr:
- Create 'logs' command for dealing with logs
- Add 'logs show' command for pulling logs from the target device
- Add 'logs clear' to erase the existing logs on the target device

newt:
- Implement the facility to encode logs for newtmgr

I'll be following up with some pull requests shortly that will implement
these. I'd welcome any feedback you might have.

TIA,
Gordon

Re: RAT (release audit tool)

[Christopher Collins]

Thanks, Justin, that is a good idea.  I'll run both of those tools.

Chris

On Sun, Feb 21, 2016 at 04:54:17PM +1100, Justin Mclean wrote:
> Hi,
> 
> It quite likely that anyone reviewing the release on the incubator will use:
> 1) Apache rat [1]
> 2) Compliance Rocks 
> 
> We might want to put a rat exclusion file together to help people and cut 
> down of the number of false positives it currently generates.
> 
> At the very least yo shovel run the tools over the source release so are 
> prepared for any issue that they might bring up.
> 
> Thanks,
> Justin
> 
> 
> 1. http://creadur.apache.org/rat/apache-rat/
> 2. http://compliance.rocks

Planning to add log facilities

[Gordon Chaffee]

Hi, I'm new to the list, and I'm working on some code to extend the
existing logs capabilities. Specifically, I'm planning to add the following:

newtmgr:
- Create 'logs' command for dealing with logs
- Add 'logs show' command for pulling logs from the target device
- Add 'logs clear' to erase the existing logs on the target device

newt:
- Implement the facility to encode logs for newtmgr

I'll be following up with some pull requests shortly that will implement
these. I'd welcome any feedback you might have.

TIA,
Gordon