Re: Android app to interact with devices powered by Mynewt OS and BLE stack

[aditi hilbert]

Hi Samurdhi,

Thanks for joining the @dev list! It’s great to hear you are interested in the 
work we are doing. The specific project you have inquired about is one we would 
love to offer for GSoC; however, the official start is a few months away and we 
are currently still working on the core elements of the OS and networking (BLE) 
stack that are essential for the Android/iOS app project. If you think you have 
the right background and experience I urge you to go through the code and docs 
for Apache Mynewt closely, stay in close touch with the progress being made, 
and suggest one or more small things to contribute in the meantime to get 
closer to the project launch. 

In the event the Android/iOS app project needs more time to take off we could 
probably roll your suggestions/contributions into a GSoC project so you are 
eligible for the credit and reward (besides the satisfaction of pushing Apache 
Mynewt forward :) ). 

thanks,
Aditi


> On Feb 16, 2016, at 8:26 PM, Samurdhi Karunarathne  
> wrote:
> 
> Hello All,
> 
> I'm Samurdhi Karunarathne and I'm a student at the Faculty of Engineering,
> University of Peradeniya, Sri Lanka. I came across this project in Jira
> intended for GSoC 2016, to develop an Android or iOS app to interact with
> devices running MyNewt OS and BLE stack. As I have considerable experience
> in this direction I am very interested in working on this project for GSoC
> 2016.
> Hope you could give me some guidelines to get myself up and aboard the
> task. Thanks in advance!
> 
> Regards,
> Samurdhi

Re: Wiki / Confluence

[aditi hilbert]

resolved. I can add users.

thanks
aditi
> On Feb 16, 2016, at 5:26 PM, aditi hilbert  wrote:
> 
> Or so I thought. I have asked Infrastructure why I don’t see that tab.
> 
> thanks,
> aditi
> 
>> On Feb 16, 2016, at 5:16 PM, aditi hilbert > > wrote:
>> 
>> I can add users.
> 

Re: Wiki / Confluence

[aditi hilbert]

We already have a confluence space:

https://cwiki.apache.org/confluence/display/MYNEWT/Apache+Mynewt+Home 


I can add users.

thanks,
aditi

> On Feb 16, 2016, at 5:11 PM, Justin Mclean  wrote:
> 
> Hi,
> 
>> Is there ASF infrastructure to support a Wiki?  Would someone mind putting 
>> together a ticket for infrastructure, so we can start capturing this stuff 
>> there?
> 
> You can ask for it here [1] under 3 wiki request. You need to know the admin 
> and initial contributors and a few other things.
> 
> Justin
> 
> 1. https://issues.apache.org/jira/servicedesk/customer/portal/1

Re: Wiki / Confluence

[Justin Mclean]

Hi,

> Is there ASF infrastructure to support a Wiki?  Would someone mind putting 
> together a ticket for infrastructure, so we can start capturing this stuff 
> there?

You can ask for it here [1] under 3 wiki request. You need to know the admin 
and initial contributors and a few other things.

Justin

1. https://issues.apache.org/jira/servicedesk/customer/portal/1

Re: Kicking off a release

[Justin Mclean]

Hi,

Who is going to act as release manager?

> The latter, I think, has been successfully resolved on dev@mynewt and 
> general@incubator

Yep agreed.

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

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?

You might also want to read this [2]. Any questions just ask I've reviewed 
(100’s?) and created many releases.

Thanks,
Justin

1. http://www.apache.org/dev/licensing-howto.html 

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

Wiki / Confluence

[Sterling Hughes]

Hey,

I'm starting to take a first stab at things like:

- Release process
- Roadmap

Etc.  It would be useful to have a WIKI to document these (we may end up 
summarizing them on the site, but I think this should live in a Wiki.)


Is there ASF infrastructure to support a Wiki?  Would someone mind 
putting together a ticket for infrastructure, so we can start capturing 
this stuff there?


Thanks,

Sterling

Kicking off a release

[Sterling Hughes]

Mynewtites,

It looks like master has stabilized, and we're pretty much done with B1 
bugs:


The remaining issues are here:

https://issues.apache.org/jira/issues/?jql=project%20%3D%20MYNEWT%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%20v0_8_0_beta1%20ORDER%20BY%20priority%20DESC

They consist of:

- Adding a download to the downloads page, which contains the release
- Fixing license dependencies

The latter, I think, has been successfully resolved on dev@mynewt and 
general@incubator -- the consensus being that we can go ahead with the 
release, and remove the LGPL dependency in the newt tool after the B1 
release, so long as we add a notice in the release notes and NOTICE file.


SO, I'll defer to the other mentors here, but I believe the process is:

- 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:

  - Source tarballs of each repository
  - A build of newt for Mac OS X and Linux

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

Does this sound right?

If so, I'll add release notes, tag, and start the [VOTE] thread.


Thanks,
Sterling

Re: Proposed changes to sys/stats

[Christopher Collins]

Thanks for the feedback, all.  I will commit the first three changes to
the develop branch, but leave proposal 4 unimplemented.

Chris

On Tue, Feb 16, 2016 at 01:35:16PM -0800, will sanfilippo wrote:
> +1 for 1, 2 and 3.
> 
> Not sure about 4. I am fine with using the macros and prefacing the element 
> names but not sure what other issues this might cause so I will abstain.
> 
> Will
> 
> > On Feb 16, 2016, at 1:13 PM, Sterling Hughes  wrote:
> > 
> > 
> >> 1. The STATS_SECT_START and STATS_SECT_END macros just define a struct;
> >> they don't create an instance.  Generally, these macros would be used
> >> in a header file so that source files can have access to the struct
> >> definition.
> >> 
> >> 2. The addition of a STATS_SECT_DECL macro.  This macro would be used in
> >> two places:
> >> * In source files to instantiate a stats struct.
> >> * In header files to expose an extern declaration of a stats
> >>   instance.
> >> 
> >> 3. As a consequence of the above two points: the names of struct
> >> instances are no longer auto-generated.  The user needs to specify the
> >> exact name.  All macros which derive the instance name from the struct
> >> name are changed: now they just accept the instance name directly.
> >> 
> > 
> > 
> > +1
> > 
> > 
> >> 4. Remove the "s" which prefaces the name of each stat field in a
> >> statistics struct.  By doing this, the STATS_SECT_VAR, STATS_INC, and
> >> STATS_INCN macros can be removed.
> >> 
> > 
> > -1
> > 
> > I think we want these macros used everywhere: they allow us more 
> > flexibility to refactor this, and there is a relatively well defined access 
> > mechanism for stats.
> > 
> > Sterling
> 

Re: Proposed changes to sys/stats

[Sterling Hughes]

1. The STATS_SECT_START and STATS_SECT_END macros just define a struct;
they don't create an instance.  Generally, these macros would be used
in a header file so that source files can have access to the struct
definition.

2. The addition of a STATS_SECT_DECL macro.  This macro would be used in
two places:
 * In source files to instantiate a stats struct.
 * In header files to expose an extern declaration of a stats
   instance.

3. As a consequence of the above two points: the names of struct
instances are no longer auto-generated.  The user needs to specify the
exact name.  All macros which derive the instance name from the struct
name are changed: now they just accept the instance name directly.




+1



4. Remove the "s" which prefaces the name of each stat field in a
statistics struct.  By doing this, the STATS_SECT_VAR, STATS_INC, and
STATS_INCN macros can be removed.



-1

I think we want these macros used everywhere: they allow us more 
flexibility to refactor this, and there is a relatively well defined 
access mechanism for stats.


Sterling