Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc2

[Justin Mclean]

Hi,

> For reference, the file that is being changed contains offsets to interrupt 
> vectors on ARM platforms.  The new (correctly) licensed functions look 
> perfectly fine to me, and I think post release (and in develop) we should 
> replace these files. 

Sounds like a fine approach to me.

Thanks,
Justin

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc2

[Sterling Hughes]

Hey Chris,

On 29 May 2016, at 13:14, Christopher Collins wrote:


I'm attaching git diffs between the following two revisions:
a: commit when BSD license text was added (mbed repo)
b: first commit to the mynewt core repo.

The Mynewt files are "b" in the attached diffs.  That is, "+++" are
changes added by Mynewt; "---" is removed by mbed.


Of course I attached the wrong diffs.  Here are the correct ones.

Sorry about that!

Chris


Thanks for doing this.

Given that we’ve already released multiple versions of Mynewt with 
CMSIS header files, we’re releasing a 0.9 and ARM has pretty much 
licensed every other version of this header file under a BSD license in 
recent years — I’d vote that we add an item in the NOTICE file, and 
release.  This is an area where we’re not wholly in accordance with 
policy, but I think the risk to the end user is very low, and all of our 
previous releases have had this issue.


For reference, the file that is being changed contains offsets to 
interrupt vectors on ARM platforms.  The new (correctly) licensed 
functions look perfectly fine to me, and I think post release (and in 
develop) we should replace these files.  But I’d like to have some run 
time with them (more than a few days), prior to releasing, in case 
anything subtle occurs that we don’t catch in our regression tests.


Justin/Chris — would that be fine for you?

Sterling

Re: [DISCUSS] A users@ mailing list for Apache Mynewt

[Greg Stein]

On Sun, May 29, 2016 at 1:27 PM, David Moshal  wrote:

> Any reason you folks aren't using Slack, Gitter, Github or equivalent
> for managing these conversation?
>

Mostly because we need archives of all discussions under our management. We
need to keep this stuff around "forever". It is hard to do that with
third-party services.

We also need discussions (and archives) that are as open to participation
as possible. email is the LCD for that. There are *many* copies of our
archives, and many tools for participation around our email lists.

Cheers,
-g

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc2

[Christopher Collins]

On Sun, May 29, 2016 at 10:56:09AM -0700, Christopher Collins wrote:
> The CMSIS-CORE files that Mynewt bundles fall into two categories:
[...]
> 2. Functional changes were made by ARM mbed before the BSD license
>was added; the oldest revisions containing the BSD license text
>are different from those in Mynewt.
> 
> The files in category 2 are the ones causing issues for us now.  Since
> the versions of these files in Mynewt are not directly derived from
> revisions containing the BSD license, I don't know what we can
> reasonably claim.

Specifically, the following files in the mynewt core repo are
problematic:

libs/cmsis-core/src/cmsis_nvic.c
hw/bsp/nrf51dk-16kbram/include/bsp/cmsis_nvic.h
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

The last four (the header files) are almost identical to one another,
and for simplicity I am considering them a single file in this email.

I'm attaching git diffs between the following two revisions:
a: commit when BSD license text was added (mbed repo)
b: first commit to the mynewt core repo.

The Mynewt files are "b" in the attached diffs.  That is, "+++" are
changes added by Mynewt; "---" is removed by mbed.

Thanks,
Chris
diff --git 
a/5b8ab176:libraries/mbed/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/cmsis_nvic.h
 
b/e08882916788cee7cb2540604f8f6ec166a1c654:hw/bsp/nrf52pdk/include/bsp/cmsis_nvic.h
old mode 100644
new mode 100755
index e1fd1a3..78d0417
--- 
a/5b8ab176:libraries/mbed/targets/cmsis/TARGET_NORDIC/TARGET_MCU_NRF51822/cmsis_nvic.h
+++ 
b/e08882916788cee7cb2540604f8f6ec166a1c654:hw/bsp/nrf52pdk/include/bsp/cmsis_nvic.h
@@ -1,48 +1,40 @@
-/* mbed Microcontroller Library
- * CMSIS-style functionality to support dynamic vectors
- 
***
- * Copyright (c) 2011 ARM Limited. All rights reserved.
- * All rights reserved.
+/**
+ * Copyright (c) 2015 Stack Inc.
  *
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ * 
+ *   http://www.apache.org/licenses/LICENSE-2.0
  *
- * 1. Redistributions of source code must retain the above copyright notice,
- *this list of conditions and the following disclaimer.
- * 2. Redistributions in binary form must reproduce the above copyright notice,
- *this list of conditions and the following disclaimer in the documentation
- *and/or other materials provided with the distribution.
- * 3. Neither the name of STMicroelectronics nor the names of its contributors
- *may be used to endorse or promote products derived from this software
- *without specific prior written permission.
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+/* mbed Microcontroller Library - cmsis_nvic
+ * Copyright (c) 2009-2011 ARM Limited. All rights reserved.
  *
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
ARE
- * DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
- * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
- * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
- * SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
- * CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT 
LIABILITY,
- * OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE 
USE
- * OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
- 
***
- */ 
+ * CMSIS-style functionality to support dynamic vectors
+ */
 
 #ifndef MBED_CMSIS_NVIC_H
 #define MBED_CMSIS_NVIC_H
 
-#define NVIC_NUM_VECTORS  (16 + 32)   // CORE + MCU Peripherals
-#define NVIC_USER_IRQ_OFFSET  16
+#include 
 
-#include "nrf51822.h"
-#include "cmsis.h"
+#define NVIC_NUM_VECTORS  (16 + 38)   // CORE + MCU Peripherals
+#define NVIC_USER_IRQ_OFFSET  16
 
+#include "nrf52xxx/nrf52.h"
 
 #ifdef __cplusplus
 extern "C" {
 #endif
 
+void NVIC_Relocate(void);
 void NVIC_SetVector(IRQn_Type IRQn, uint32_t vector);
 uint32_t NVIC_GetVector(IRQn_Type IRQn);
 
diff --git 

Re: [DISCUSS] A users@ mailing list for Apache Mynewt

[David Moshal]

Any reason you folks aren't using Slack, Gitter, Github or equivalent
for managing these conversation?

Dave



On Sun, May 29, 2016 at 12:15 AM, Greg Stein  wrote:
> I don't think users@ makes sense.
>
> I just looked at the past 30 days, and there *might* be 10 messages. That
> isn't exactly an encumbrance upon the dev list. So now you're talking about
> partitioning the overall community into smaller parts. Parts that cannot
> reach "critical mass".
>
> Counterpoint: the Subversion project took THREE YEARS before creating a
> separate users list. Mynewt isn't anything close to a user-driven project
> like svn. And the project is just *months* old.
>
> The users of mynewt are unlikely to be noobs who cannot deal with people on
> the dev@ list. This is a low-level project. It seems irrational to believe
> they are not "lifting the hood" to look at the mynewt code; there is no
> "scaring them off". They are quite likely to be great participants in dev
> discussion. We want them *here* where we can talk with them.
>
> Cheers,
> -g
>
> On Sun, May 22, 2016 at 12:07 PM, Sterling Hughes 
> wrote:
>
>> +1 on a users mailing list, and I think David described it perfectly below.
>>
>> Originally, I was for all support being on dev@, as pointed out in other
>> mails, it is good for the project/code for developers to hear directly from
>> the users.  IMO The best way to make a project easy to use and work well,
>> is to have developers do customer support: it appeals to both pride and
>> laziness.
>>
>> However, I think it can be intimidating to post to a dev@ list as a first
>> time user, especially on something like an OS.  We want to make that as
>> easy as possible to get new users in.  So, I'm for having a separate list,
>> BUT I think anyone developing on the project should strongly consider
>> joining that list and providing support.  I certainly will be.
>>
>> Also, I like the new mailing list archive -- we should definitely link to
>> these on the doc pages.
>>
>> Cheers,
>>
>> Sterling
>>
>>
>> On 5/20/16 7:55 AM, David G. Simmons wrote:
>>
>>> As a n00b, I’ll chime in here with my experience so far … Just my $0.02,
>>> so take it as you will. I’ve been involved in a few ‘new’
>>> product/protocol/platform development efforts over the years though.
>>>
>>> As a new user and (potential) developer, the lack of a ‘user’ list was
>>> (as another has previously stated) a bit intimidating. I’m not (yet) a
>>> mynewt developer, just a hacker trying to get stuff working. I finally bit
>>> the bullet and posted to the dev list and was obviously pleasantly
>>> surprised by both the speed and friendliness of the response. There is a
>>> LOT of value in having the folks actually developing the system see all the
>>> questions from the users. I know it can be a distraction from the ‘real’
>>> work to get silly questions from new users, but in my experience, the
>>> success of a platform is in many ways highly dependent on the experience of
>>> new users. If someone new can’t start using the platform, then you wont’
>>> have new users, and …
>>>
>>> I found the archives, and attempted to go through them as best I could in
>>> order to find answers to questions I was having initially. I figured most
>>> of them out on my own, from repeated trips through the docs, etc., but the
>>> email archives could be much more helpful. The problem is that the mail
>>> archives are … so 1998. Not searchable, only navigable by year/month, etc.
>>> Having a proper interface to the mail archives would make them much more
>>> useful to users. Even the mail-archive.com interface — which has search
>>> — would work nicely. Having a forum — along the lines of phpBB2, though
>>> those are notoriously hard to keep spammers out of — with an email-to-forum
>>> gateway would also be helpful.
>>>
>>> Back to hacking …
>>>
>>> dg
>>>
>>>
>>>
>>>
>>> On May 19, 2016, at 4:42 PM, James Pace  wrote:

 I’d personally like to see these separated. Many of the comments that
 are coming in are routine (though very informative) and do not inform the
 design or development of Apache Mynewt.

 And, besides, it is likely that you will have “user” and “dev”  sourced
 to the same mailbox or mail filter!

 On May 19, 2016, at 11:12, p...@wrada.com wrote:

 I¹d prefer to keep them together for now.  As this is new, I think that
> developers are going to learn a lot from the users issues or questions,
> and vice versa.  I agree that this will get too much at some point, but
> I¹m really getting a lot from seeing the user and developer issues
> together.
>
>
> On 5/19/16, 11:08 AM, "aditi hilbert"  wrote:
>
> Hi,
>>
>> With Mynewt attracting an increasing number of both users and
>> developers
>> of various levels, it might make practical sense to have a users@
>> mailing
>> list separate 

Re: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc2

[Christopher Collins]

Thanks again, Justin.  My responses are inline below.  I rearranged your
email such that your first finding comes last, since it is the most
difficult to address :).

On Sun, May 29, 2016 at 11:23:25AM +1000, Justin Mclean wrote:
[...]

> The core release notes is out of data and talks about March release
> with the next release being in April and it being the "second source
> release”.The readme is also not up to date, and the supported board
> list seem to be missing a few boards?

The outdated release notes is definitely our screw up.  However, the
list of supported platforms in the readme file looks correct to me.  The
only discrepancy I see is that the Arduino 101 isn't mentioned in the
list, but I think that is correct since this target is not fully
supported yet.  Is there another one that I missed?

> The newt release notes are also out of date and refers to the "first
> source release”.

Darn.  We should have caught this one as well.

> I would suggest that the artefact names be renamed to include “mynewt”
> not “newt” especially the core one for the next release.

That sounds reasonable.  I think we should just add "mynewt" to all
three component names, but I am interested in hearing others' thoughts.

> For core is there now any way we can improve on this situation?  "This
> product bundles additional files from CMSIS-CORE, but these files are
> missing licensing information.”

Yes, this one is indeed troubling.  To provide some background:

Recent CMSIS-CORE releases contain the BSD license text, but the older
releases do not, so it is possible that the distributor simply forgot to
add the license text in the older releases.  Back when the CMSIS-CORE files were
added to Mynewt core, we added versions which lacked the BSD license text.

The CMSIS-CORE files that Mynewt bundles fall into two categories:
1. Revisions exist which are identical to those which were
   originally included in Mynewt; the only difference being the
   addition of the BSD license.

2. Functional changes were made by ARM mbed before the BSD license
   was added; the oldest revisions containing the BSD license text
   are different from those in Mynewt.

The licensing issue was easy to solve for the "category 1" files: we
just replaced our old copies of these files with the corresponding
BSD-licensed revisions.

The files in category 2 are the ones causing issues for us now.  Since
the versions of these files in Mynewt are not directly derived from
revisions containing the BSD license, I don't know what we can
reasonably claim.  Intuitively, I feel like the Mynewt copies of these
files are "more or less" derived from the revisions containing the BSD
text, but obviously that is not a legal argument!

Do you have suggestions on how best to proceed?

(In case I gave the opposite impression, I agree that keeping things in
their current state is not a solution).

Thanks,
Chris

Re: [DISCUSS] A users@ mailing list for Apache Mynewt

[Aethaniel]

Hi,

For that purpose, the github issues feature may be used, to my mind.

This feature also contributes in building a good knowledge base.

I know this project isn't hosted on github and offer only a mirror there but it 
doesn't disallow using its features.

My 2 cents,

Thibaut VIARD


On 29 May 2016 09:15:18 CEST, Greg Stein  wrote:
>I don't think users@ makes sense.
>
>I just looked at the past 30 days, and there *might* be 10 messages.
>That
>isn't exactly an encumbrance upon the dev list. So now you're talking
>about
>partitioning the overall community into smaller parts. Parts that
>cannot
>reach "critical mass".
>
>Counterpoint: the Subversion project took THREE YEARS before creating a
>separate users list. Mynewt isn't anything close to a user-driven
>project
>like svn. And the project is just *months* old.
>
>The users of mynewt are unlikely to be noobs who cannot deal with
>people on
>the dev@ list. This is a low-level project. It seems irrational to
>believe
>they are not "lifting the hood" to look at the mynewt code; there is no
>"scaring them off". They are quite likely to be great participants in
>dev
>discussion. We want them *here* where we can talk with them.
>
>Cheers,
>-g
>
>On Sun, May 22, 2016 at 12:07 PM, Sterling Hughes 
>wrote:
>
>> +1 on a users mailing list, and I think David described it perfectly
>below.
>>
>> Originally, I was for all support being on dev@, as pointed out in
>other
>> mails, it is good for the project/code for developers to hear
>directly from
>> the users.  IMO The best way to make a project easy to use and work
>well,
>> is to have developers do customer support: it appeals to both pride
>and
>> laziness.
>>
>> However, I think it can be intimidating to post to a dev@ list as a
>first
>> time user, especially on something like an OS.  We want to make that
>as
>> easy as possible to get new users in.  So, I'm for having a separate
>list,
>> BUT I think anyone developing on the project should strongly consider
>> joining that list and providing support.  I certainly will be.
>>
>> Also, I like the new mailing list archive -- we should definitely
>link to
>> these on the doc pages.
>>
>> Cheers,
>>
>> Sterling
>>
>>
>> On 5/20/16 7:55 AM, David G. Simmons wrote:
>>
>>> As a n00b, I’ll chime in here with my experience so far … Just my
>$0.02,
>>> so take it as you will. I’ve been involved in a few ‘new’
>>> product/protocol/platform development efforts over the years though.
>>>
>>> As a new user and (potential) developer, the lack of a ‘user’ list
>was
>>> (as another has previously stated) a bit intimidating. I’m not (yet)
>a
>>> mynewt developer, just a hacker trying to get stuff working. I
>finally bit
>>> the bullet and posted to the dev list and was obviously pleasantly
>>> surprised by both the speed and friendliness of the response. There
>is a
>>> LOT of value in having the folks actually developing the system see
>all the
>>> questions from the users. I know it can be a distraction from the
>‘real’
>>> work to get silly questions from new users, but in my experience,
>the
>>> success of a platform is in many ways highly dependent on the
>experience of
>>> new users. If someone new can’t start using the platform, then you
>wont’
>>> have new users, and …
>>>
>>> I found the archives, and attempted to go through them as best I
>could in
>>> order to find answers to questions I was having initially. I figured
>most
>>> of them out on my own, from repeated trips through the docs, etc.,
>but the
>>> email archives could be much more helpful. The problem is that the
>mail
>>> archives are … so 1998. Not searchable, only navigable by
>year/month, etc.
>>> Having a proper interface to the mail archives would make them much
>more
>>> useful to users. Even the mail-archive.com interface — which has
>search
>>> — would work nicely. Having a forum — along the lines of phpBB2,
>though
>>> those are notoriously hard to keep spammers out of — with an
>email-to-forum
>>> gateway would also be helpful.
>>>
>>> Back to hacking …
>>>
>>> dg
>>>
>>>
>>>
>>>
>>> On May 19, 2016, at 4:42 PM, James Pace  wrote:

 I’d personally like to see these separated. Many of the comments
>that
 are coming in are routine (though very informative) and do not
>inform the
 design or development of Apache Mynewt.

 And, besides, it is likely that you will have “user” and “dev” 
>sourced
 to the same mailbox or mail filter!

 On May 19, 2016, at 11:12, p...@wrada.com wrote:

 I¹d prefer to keep them together for now.  As this is new, I think
>that
> developers are going to learn a lot from the users issues or
>questions,
> and vice versa.  I agree that this will get too much at some
>point, but
> I¹m really getting a lot from seeing the user and developer issues
> together.
>
>
> On 5/19/16, 11:08 AM, "aditi hilbert"  wrote:
>
> Hi,
>>

Re: Correct way to add a task that only runs once

[James Howarth]

Thank you Sterling.  I will take a look at the information you pointed me
to.

Cheers
James


On Sat, May 28, 2016 at 2:54 PM, Sterling Hughes 
wrote:

> Hi James,
>
> Callouts are perfect for this type of function.  I’d recommend
> multiplexing this within the task context you are running out of.
>  Essentially the logic works like:
>
> - Turn the LED on
> - Set a callout for 1 second to turn the LED back off
>
> If your task is waiting on an event queue, it will process that event in
> one second.
>
> More information on callouts and event queues can be found here:
>
> - Tutorial on using these:
> http://mynewt.apache.org/os/tutorials/event_queue/
> - Callouts: http://mynewt.apache.org/os/core_os/callout/callout/
> - Event Queues:
> http://mynewt.apache.org/os/core_os/event_queue/event_queue/
>
> You don’t need to add a specific task for the LED function, you can just
> multiplex it as an event.  If you want to create a separate task (so that
> it has higher priority, or doesn’t block/isn’t blocked by other functions),
> you can.
>
> Sterling
>
>
> On 28 May 2016, at 14:39, James Howarth wrote:
>
> Hi,
>>
>> I want to be able to flash an LED on for ~1 second when some condition
>> occurs.  I don't want this to be flashing all the time like the blinky
>> example.
>>
>> What's the right way to add a task that runs only once?  Or should I not
>> be
>> using a task at all for this?
>>
>> Cheers
>> James
>>
>