Re: installing the Newt
I have committed the changes to the develop branch. Now all go imports use the vanity domain. Unfortunately, this is going cause a bit of pain for the current users because the newt sources are now in the wrong directory. To correct this problem, you will need to move the old newt path to the new one: $ mkdir -p "$GOPATH"/src/mynewt.apache.org && mv $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt "$GOPATH"/src/mynewt.apache.org/newt If you plan on building older versions of newt, you should link the path rather than move it: $ mkdir -p "$GOPATH"/src/mynewt.apache.org && ln -s $GOPATH/src/git-wip-us.apache.org/repos/asf/incubator-mynewt-newt "$GOPATH"/src/mynewt.apache.org/newt Sorry for the hassle. Yes, we definitely need to include convenience binaries in the next release :). Chris On Wed, Mar 02, 2016 at 11:21:49PM -0800, Christopher Collins wrote: > Nice! That seems to work. I guess I completely glossed over those > vanity URL emails. I will make the necessary changes to the develop > branch. Unfortunately, I'm afraid it is too late to fix 0.8.0-b1. > > Chris > > On Wed, Mar 02, 2016 at 10:40:53PM -0800, Sterling Hughes wrote: > > > > > > > > When pointed at the apache server, on the other hand, "go get" seems to > > > require the ".git" suffix. An I mentioned earlier, this results in the > > > creation of a directory that also has the ".git" suffix. > > > > > > The problem is: the behavior of "git clone" is in conflict with the > > > behavior of "go get", at least with regards to the apache git server. > > > At one point the installation documentation was accurate, but it seems > > > we have since opted for git-friendliness rather than > > > go-get-friendliness. > > > > > > We will need to find a simpler workaround. In the meantime, we should > > > at least update the documentation. Also, soon newt binaries will be > > > available for download which help to alleviate problems with go. > > > > > > > Weren't Todd & Aditi making "mynewt.apache.org" a valid import path, > > that would point to the proper Apache git repository? I thought this > > would solve that problem? > > > > Sterling
Re: installing the Newt
Hi, > Nice! That seems to work. I guess I completely glossed over those > vanity URL emails. I will make the necessary changes to the develop > branch. Unfortunately, I'm afraid it is too late to fix 0.8.0-b1. Would be easy enough to release a 0.8.1 if people think the fix is important enough to be released. I know there are planned releases coming up, but that doesn’t mean you can have unplanned ones. In theory anyone can make a release and put it up for a PPMC vote. Thanks, Justin
Re: installing the Newt
When pointed at the apache server, on the other hand, "go get" seems to require the ".git" suffix. An I mentioned earlier, this results in the creation of a directory that also has the ".git" suffix. The problem is: the behavior of "git clone" is in conflict with the behavior of "go get", at least with regards to the apache git server. At one point the installation documentation was accurate, but it seems we have since opted for git-friendliness rather than go-get-friendliness. We will need to find a simpler workaround. In the meantime, we should at least update the documentation. Also, soon newt binaries will be available for download which help to alleviate problems with go. Weren't Todd & Aditi making "mynewt.apache.org" a valid import path, that would point to the proper Apache git repository? I thought this would solve that problem? Sterling
installing the Newt
After going through some of the documentary on how to get to get start, I discovered that I need to install newt. I ran the following commands successively $ sudo apt-get install git $ sudo apt-get install libcurl4-gnutls-dev $ sudo apt-get install golang in my home directory,i ran this $ mkdir -p dev/go $ cd dev/go $ cd ../.. $ export GOPATH= dev/go I opened the .bashrc document and added export GOPATH=dev/go after running $ go get git-wip-us.apache.org/repos/asf/incubator-mynewt-newt.git/newt I get the following error. package git-wip-us.apache.org/repos/asf/incubator-mynewt-newt/newt/cli: unrecognized import path "git-wip-us.apache.org/repos/asf/incubator-mynewt-newt/newt/cli" please can somebody help me with this? or tell me what to do?? Thanks in advance.
Re: Analysis of our first release process
Hi, > What type of warnings do we want to provide in the Newt tool for non-ASF > compatible licenses. > > - Do we want to have a list of these 3rd party package repositories in the > official ASF documentation? General practice is to prompt the user when installing something that is not Category A. > - How do we provide binary and source distributions of the Newt tool. For the next vote vote on both a source and convenience binary release at the same time - now the GPL dependancy is gone. Thanks, Justin
Re: Interested inYour Gsoc Project Project
Hi Nges, Thanks for your interest. Can you comment on the GSoC tickets within the ASF JIRA? I think it would be great if you came on and helped us with the regression testing: we're going to be doing a ton of work on that this summer, and would love the help. Cheers, Sterling On 3/2/16 1:41 PM, Nges B wrote: Please I am also interested in the" GATT based BLE profiles, Services, and Protocols" will also like to have some directives on this project. I have taken courses on Computer Networks and Protocols, Computer Architectures and Operating Systems . I know my knowledge from the above mentioned courses and the research I am already doing on this projects coupling with my C,C++ and Web programming skill is going to help me through with this organization.
Re: Analysis of our first release process
On 3/1/16 4:02 PM, Justin Mclean wrote: Hi, Great summary! 0.8.0-b1 is exceptional in that it is our first release. In subsequent releases we will want to specify what has been added or fixed since the last release, as well as highlight known issues. JFYI this is usually done in a separate file call RELEASE_NOTES or similar. For example see [1] but there no prescribed way of doing this it’s up. yes. I think next release has to spend quite a bit of time on this file, given the early state of OS releases, we need to be super clear with people about where we are. (4) Fix our release naming procedure. Again up to the PMC how they name releases, other than having the project name, ‘incubating’ and (optionally) apache. “rc" (for release candidate) is usually used rather than "b” tends to be typical but again totally up to the PMC. That those names seem fine to me. Having the release process documented would be a good idea so that other committers can make a release if they want. +1. I think we'll need to document two things on the Mynewt wiki, branching strategy and release process. 1- We should document the current release process that we used, along with thoughts on the improvements 2- I'll work on documenting our branching strategy. I think there are a number of things we'll want to discuss re [1], including: - How do we manage non-ASF compatible packages. Do they get distributed on Github, and does the ASF repository point to these external packages. What type of warnings do we want to provide in the Newt tool for non-ASF compatible licenses. - Do we want to have a list of these 3rd party package repositories in the official ASF documentation? - How do we provide binary and source distributions of the Newt tool. My instinct is that close to 99% of our users will take the newt binary as opposed to source, so we need to make this easy, while still following the ASF philosphy of source first releases. - How do we want to allow people to access the ASF package repository with releases of newt. For example, by default should a newt release point to a specific tag on the incubator-mynewt-larva package repository? Should we allow people to chose different versions based on a tag / branch strategy here? - How do we facilitate upgrade of packages when migrating to a new release. Chris, if you take a first pass at this with what we've done for this release, I can take a second pass, and then let's send around to the list for discussion? Cheers, Sterling
Interested in your Project
Hello Everyone. I am Nges Brian a computer Engineering Student from the Faculty of Engineering and technology University of Buea. I came across this project while going over the GSOC Projects for 2016. I am a good C,C++ and Web programmer. I have done several projects with the above technology. I will like to work with you guys on this summer project. I am very interested on this project because I planned to specialize on embedded systems and I think this will be the best way and place for me to start. I will start by requesting for more details on the GSOC project especially the " White box and regression test utilities for various Mynewt OS components" . secondly I will like to request for material that can help me start work on the above project without any further delay as time is not more on my side. I promise If i do my Gsoc in th this organization, I will continue work with you even after the summer of code. Thanks and hope to here from you soon. Cheers
Re: trivial mbuf api thoughts: os_mbuf_free() and os_mbuf_free_chain()
On 3/2/16 11:45 AM, will sanfilippo wrote: I was hoping that the other mbuf API exposed would be enough for users and they would never need to call os_mbuf_free. I also think that when you unlink something from a list, setting its next pointer to NULL is just good practice. I was just trying to avoid the myriad bugs I have seen in the past by having both of these api exposed. But I am fine if folks want to keep it. I think we want both functions, people who work with mbufs (me!) are very used to m_free() and m_freem(). I was debating whether we should call free_chain(), freem() instead, but decided free_chain() was clearer. I would be fine if people thought I was wrong, and wanted to rename it to freem(). Sterling
