You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@mynewt.apache.org by cc...@apache.org on 2016/11/10 02:36:08 UTC
[incubator-mynewt-blinky] Git Push Summary
Repository: incubator-mynewt-blinky
Updated Branches:
refs/heads/1_0_0_b1_dev [created] ea4b8b8ba
Re: [HEADS UP] MERGE INTO MASTER!
Posted by marko kiiskila <ma...@runtime.io>.
I created https://issues.apache.org/jira/browse/MYNEWT-482 <https://issues.apache.org/jira/browse/MYNEWT-482>
What I usually do is I start ‘newt debug’, and then issue flash erase
commands via gdb. Which is not too bad either.
> On Nov 10, 2016, at 2:00 PM, David G. Simmons <sa...@mac.com> wrote:
>
>
>> On Nov 10, 2016, at 4:59 PM, Kevin Townsend <ke...@adafruit.com> wrote:
>>
>>
>>> Backwards-compatiblity-breaking changes have been made to the boot
>>> loader. Consequently, before using the latest, you will need to
>>> completely erase the boot and images slots in your devices' flash and
>>> upload a new boot loader. The latest code may appear to work with an
>>> old boot loader, but you will eventually run into issues if you perform
>>> image management (image list, upload, etc.). The least painful way
>>> forward is to just erase your flash entirely, replace the boot loader,
>>> and forget about it. Sorry about this this one; hopefully it is the
>>> last time!
>> Would an 'erase' command make sense to add to newt? I always end up firing up JLinkExe to erase my chips, which is easy enough, but being able to do something like 'newt erase' might be useful as a faster solution without having to lookup the connection string and part ID every time and for every chip.
>
> +10 :-)
>
>>> A more comprehensive list of changes will go out soon, but I thought
>>> this one deserved special mention.
>> This will be very useful. I think we've tackled all the breaking changes in our own codebase, but having them all in one place will help make sure we didn't miss any interesting new features. 0.10.0 is a really nice improvement, though. I'm impressed at how much you guys got into this release, and how much it's improved the system overall!
>>
>> K.
>
> --
> David G. Simmons
> (919) 534-5099
> Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_blog> • Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter <http://twitter.com/TechEvangelist1> • GitHub <http://github.com/davidgs>
> /** Message digitally signed for security and authenticity.
> * If you cannot read the PGP.sig attachment, please go to
> * http://www.gnupg.com/ <http://www.gnupg.com/> Secure your email!!!
> * Public key available at keyserver.pgp.com <http://keyserver.pgp.com/>
> **/
> ♺ This email uses 100% recycled electrons. Don't blow it by printing!
>
> There are only 2 hard things in computer science: Cache invalidation, naming things, and off-by-one errors.
>
>
Re: [HEADS UP] MERGE INTO MASTER!
Posted by "David G. Simmons" <sa...@mac.com>.
> On Nov 10, 2016, at 4:59 PM, Kevin Townsend <ke...@adafruit.com> wrote:
>
>
>> Backwards-compatiblity-breaking changes have been made to the boot
>> loader. Consequently, before using the latest, you will need to
>> completely erase the boot and images slots in your devices' flash and
>> upload a new boot loader. The latest code may appear to work with an
>> old boot loader, but you will eventually run into issues if you perform
>> image management (image list, upload, etc.). The least painful way
>> forward is to just erase your flash entirely, replace the boot loader,
>> and forget about it. Sorry about this this one; hopefully it is the
>> last time!
> Would an 'erase' command make sense to add to newt? I always end up firing up JLinkExe to erase my chips, which is easy enough, but being able to do something like 'newt erase' might be useful as a faster solution without having to lookup the connection string and part ID every time and for every chip.
+10 :-)
>> A more comprehensive list of changes will go out soon, but I thought
>> this one deserved special mention.
> This will be very useful. I think we've tackled all the breaking changes in our own codebase, but having them all in one place will help make sure we didn't miss any interesting new features. 0.10.0 is a really nice improvement, though. I'm impressed at how much you guys got into this release, and how much it's improved the system overall!
>
> K.
--
David G. Simmons
(919) 534-5099
Web <https://davidgs.com/> • Blog <https://davidgs.com/davidgs_blog> • Linkedin <http://linkedin.com/in/davidgsimmons> • Twitter <http://twitter.com/TechEvangelist1> • GitHub <http://github.com/davidgs>
/** Message digitally signed for security and authenticity.
* If you cannot read the PGP.sig attachment, please go to
* http://www.gnupg.com/ <http://www.gnupg.com/> Secure your email!!!
* Public key available at keyserver.pgp.com <http://keyserver.pgp.com/>
**/
♺ This email uses 100% recycled electrons. Don't blow it by printing!
There are only 2 hard things in computer science: Cache invalidation, naming things, and off-by-one errors.
Re: [HEADS UP] MERGE INTO MASTER!
Posted by Kevin Townsend <ke...@adafruit.com>.
> Backwards-compatiblity-breaking changes have been made to the boot
> loader. Consequently, before using the latest, you will need to
> completely erase the boot and images slots in your devices' flash and
> upload a new boot loader. The latest code may appear to work with an
> old boot loader, but you will eventually run into issues if you perform
> image management (image list, upload, etc.). The least painful way
> forward is to just erase your flash entirely, replace the boot loader,
> and forget about it. Sorry about this this one; hopefully it is the
> last time!
Would an 'erase' command make sense to add to newt? I always end up
firing up JLinkExe to erase my chips, which is easy enough, but being
able to do something like 'newt erase' might be useful as a faster
solution without having to lookup the connection string and part ID
every time and for every chip.
> A more comprehensive list of changes will go out soon, but I thought
> this one deserved special mention.
This will be very useful. I think we've tackled all the breaking changes
in our own codebase, but having them all in one place will help make
sure we didn't miss any interesting new features. 0.10.0 is a really
nice improvement, though. I'm impressed at how much you guys got into
this release, and how much it's improved the system overall!
K.
Re: [HEADS UP] MERGE INTO MASTER! (was: Re: 1_0_0_b1_dev branches)
Posted by Christopher Collins <cc...@apache.org>.
On Thu, Nov 10, 2016 at 08:04:45PM +0000, Sterling Hughes wrote:
> just making sure people see this :)
This is the final heads up :). I'll be merging develop into master
shortly.
For those who are interested in using the latest code, there is one
major change you should know about prior to pulling:
Backwards-compatiblity-breaking changes have been made to the boot
loader. Consequently, before using the latest, you will need to
completely erase the boot and images slots in your devices' flash and
upload a new boot loader. The latest code may appear to work with an
old boot loader, but you will eventually run into issues if you perform
image management (image list, upload, etc.). The least painful way
forward is to just erase your flash entirely, replace the boot loader,
and forget about it. Sorry about this this one; hopefully it is the
last time!
A more comprehensive list of changes will go out soon, but I thought
this one deserved special mention.
Thanks,
Chris
[HEADS UP] MERGE INTO MASTER! (was: Re: 1_0_0_b1_dev branches)
Posted by Sterling Hughes <st...@apache.org>.
just making sure people see this :)
On 10 Nov 2016, at 19:36, Christopher Collins wrote:
> FYI - I will be merging the develop branch into master later today. If
> you are using the master branch, and you are not prepared to switch over
> to the latest, then be careful with git pulls and newt syncs!
>
> Thanks,
> Chris
>
> On Thu, Nov 10, 2016 at 08:30:28AM -0800, Christopher Collins wrote:
>> (changing subject to prevent mail from being categorized as a commit)
>>
>> On Thu, Nov 10, 2016 at 01:23:36PM +0100, Sterling Hughes wrote:
>>> Is the idea to merge these from develop or master?
>>>
>>> I think we should probably merge develop->master now, prior to branching
>>> anything. We should only be branching releases off of master (which
>>> I\u2019m assuming is the intention.)
>>
>> Oops - I forgot about master when I created these branches. I don't
>> think it makes much of a difference in practice which branch the dev
>> branches come from, but I agree that using master feels more correct.
>> It is probably best to delete these branches and recreate them after
>> merging develop to master. If there are no objections, I will do this
>> in the next few hours.
>>
>> Thanks,
>> Chris
Re: 1_0_0_b1_dev branches
Posted by Christopher Collins <cc...@apache.org>.
FYI - I will be merging the develop branch into master later today. If
you are using the master branch, and you are not prepared to switch over
to the latest, then be careful with git pulls and newt syncs!
Thanks,
Chris
On Thu, Nov 10, 2016 at 08:30:28AM -0800, Christopher Collins wrote:
> (changing subject to prevent mail from being categorized as a commit)
>
> On Thu, Nov 10, 2016 at 01:23:36PM +0100, Sterling Hughes wrote:
> > Is the idea to merge these from develop or master?
> >
> > I think we should probably merge develop->master now, prior to branching
> > anything. We should only be branching releases off of master (which
> > I\u2019m assuming is the intention.)
>
> Oops - I forgot about master when I created these branches. I don't
> think it makes much of a difference in practice which branch the dev
> branches come from, but I agree that using master feels more correct.
> It is probably best to delete these branches and recreate them after
> merging develop to master. If there are no objections, I will do this
> in the next few hours.
>
> Thanks,
> Chris
1_0_0_b1_dev branches
Posted by Christopher Collins <cc...@apache.org>.
(changing subject to prevent mail from being categorized as a commit)
On Thu, Nov 10, 2016 at 01:23:36PM +0100, Sterling Hughes wrote:
> Is the idea to merge these from develop or master?
>
> I think we should probably merge develop->master now, prior to branching
> anything. We should only be branching releases off of master (which
> I\u2019m assuming is the intention.)
Oops - I forgot about master when I created these branches. I don't
think it makes much of a difference in practice which branch the dev
branches come from, but I agree that using master feels more correct.
It is probably best to delete these branches and recreate them after
merging develop to master. If there are no objections, I will do this
in the next few hours.
Thanks,
Chris
Re: [incubator-mynewt-blinky] Git Push Summary
Posted by Kevin Townsend <ke...@adafruit.com>.
On 10/11/16 13:23, Sterling Hughes wrote:
> Is the idea to merge these from develop or master?
>
> I think we should probably merge develop->master now, prior to
> branching anything. We should only be branching releases off of
> master (which I\u2019m assuming is the intention.)
>
+1 for this. :) It's difficult to do multi person development today
against develop since everyone needs to ensure they are on the same
commit, but there are so many important changes in develop that working
against master isn't viable today. That said, all the changes so far
have been worth the trouble and it will never be easier to break things
so if it takes more time it's better to drag it out a bit longer.
Re: [incubator-mynewt-blinky] Git Push Summary
Posted by Sterling Hughes <st...@apache.org>.
Is the idea to merge these from develop or master?
I think we should probably merge develop->master now, prior to branching
anything. We should only be branching releases off of master (which
I\u2019m assuming is the intention.)
Sterling
On 10 Nov 2016, at 3:36, ccollins@apache.org wrote:
> Repository: incubator-mynewt-blinky
> Updated Branches:
> refs/heads/1_0_0_b1_dev [created] ea4b8b8ba
Re: [incubator-mynewt-blinky] Git Push Summary
Posted by Sterling Hughes <st...@apache.org>.
Is the idea to merge these from develop or master?
I think we should probably merge develop->master now, prior to branching
anything. We should only be branching releases off of master (which
I\u2019m assuming is the intention.)
Sterling
On 10 Nov 2016, at 3:36, ccollins@apache.org wrote:
> Repository: incubator-mynewt-blinky
> Updated Branches:
> refs/heads/1_0_0_b1_dev [created] ea4b8b8ba