Continuing the discussion from Bug bounty: Kill the 'Cyan flash of death':
@rlogiacco can you provide more detail for what you're seeing? What pattern of lights do you see on the LEDs? Can you send a video? When you say 'the Web IDE is not running anymore', what errors or unexpected behaviors are you seeing? Same for Eclipse.
Also, have you tried a factory reset to see if that will get things back into working order?
The factory reset, yes, actually I did it twice.
Regarding the behavior Iām seeing a flashing blue led, Iāll make a video as soon as Iāll be able to flash again through the web ide: at the moment Iām constantly getting error 400.
When I say the web ide is not running, I meant to say itās not flashing. Initially I was hitting the flash button (in the ide) and getting nothing on the 
, just waiting indefinitely. After a factory reset I got the blinking blue led as a consequence of hitting the flash button. Now Iām getting a 400 error when executing the verify operation.
Hi @rlogiacco,
Hmm. I rolled out some changes to the cloud today, itās possible we had bad timing. Can you try refreshing your browser, and trying a verify again? Any other details you can provide would be helpful (which browser, what core is selected, what time you tried, etc).
Thanks!
David
I confirm the IDE is working as expected now: Iām abel to flash the with no further issues.
We can mark this as SOLVED, thanks a million.
@Dave could you please explain how the āsoft pushā to the Cloud server works on Fridays (and/or Sundaysā¦ aka Fundays) ā¦ and how this relates to the compile/server2 branch of the core-firmware github repo?
This just strated again: Iām currently uploading a video on youtube to share it with you
Sure thing! Apologies if this is too vague or too specific, happy to go into more / less detail on whatever. 
tl;dr edition:
āsoft pushā is my unofficial phrase for when we do a small or incremental rollout of a new feature, first on staging, and then on production before encouraging everyone to start hitting it, just so we have a chance to make sure we like the interface, things work as expected, etc.
In particular during this last weekend, I had been testing changes on staging all week, and I really wanted to make sure people using the CLI were able to flash and compile locally as soon as possible. I had been nearly ready for a Thursday rollout, but I was still seeing a few bugs. So I spent a chunk of time Saturday / Sunday to test and fix those, and then do a rollout. I think most of those changes will be in the Sprint blog post.
extended edition:
Generally when improvements are ready to be released, we try to do rollouts during low impact times, and when most of the team is available to respond if problems arise. Right now I think thatās generally something like Thursday mid-day. 
Since a lot changed in the firmware during this last sprint (thanks to a ton of great pull requests and testing), there continues to be testing of the latest master. At the moment we just got out of our planning meeting, so I think Zac and Mohit are still testing the changes to make sure everything still works as expected.
The cloud build service pulls the compile-server2 branch when doing compiles for the build IDE and for the CLI and API requests. In this sense the compile-server2 branch is the āstable / releaseā branch, and the master branch is the live development one. When we feel really good about a version of the firmware, we will sometimes tag a commit with a special āspark_abcā tag (spark_1, spark_2, etc). This special golden version is used when auto-updating cores running Tinker from the factory, and the latest tagged version is used during manufacturing as well.
Thanks!
David
Dave, Iāve heard Serial1 ring buffer changes are going to be rolled out to cloud āearlier next (=this) weekā. Do you have more detailed estimate? Currently even compile-staging branch does not have related commits
Hi @ryotsuke,
Those guys have been testing on master and compiling locally, so we havenāt needed to pull the staging branch up to date yet. I believe Mohit is actually working on this right now and heās hoping to be done testing by the end of the day today. So we should be able to move the compile-server2 branch up to master Tuesday / Weds at the latest if there arenāt new issues.
Thanks,
David
@dave Ok, so if Iām getting this correctly when you say āsoft pushā you really are not implying we should see any kind of a change to what the web IDE compiles with, and itās just an intermediate commit point that you are testing between master and compile-server2, aka compile-staging? Seems like just over the weekend though a bunch of people noticed changes to code that was previously working, which is why I assumed some changes must have happened recently on compile-server2. I guess you are tweaking the compiler though which is not tracked on a repo.
Which leads me to the next questionā¦ since changes are not pulled into compile-server2 via a pull request, we donāt really know when exactly it changed, because it always has some old date of a prior commit that happened to master merged into it, so when we look at compile-server2 we have to remember what the date was the last time we looked at it (currently itās Jan 31st), to know if it in fact changed recently. Is there a better way to know when exactly compile-server2 has changed? Or will it always become current with master when it changes?
Ahh, sure that makes sense. Generally when we pull that branch forward we merge changes from master into it, so I think the history or date should generally be reflected. I think they ought to be aligned after an update, but I agree that is less than ideal when trying to track progress.
I think we try to make a point of announcing when the stable branch is updated, but I wonder what would be easier to track? If we had a Github issue / milestone for āpromoting firmware updates to stableā or something each time ā would that be better?
Maybe tag it as spark_2.01 and only use major releases for factory firmware? Then you can at least have a good reference point to be able to say the web IDE is currently at spark_2.01 which should mean the same thing on master or compile-server2.
I like the idea of using minor versions; I think in general we could be more explicit about versioning everything from the firmware to the API and all of the tools weāve built in between.
This is the one bug that we need to fix before merging master into compile-server2:
Itās @satishgnās top priority today.
b.t.w that would be a good thing to have this bug as a separate feature in future
I mean āDo not clear WiFi credentials when factory resetā or "Force reflash of original firmware without touching wifi credentials"
Iām using OTA updates, so every factory reset means I need to attach core again and set credentials, which is not very comfortable if work area of actual device is far from PC
Hm, good call, same thing has occurred to me before. Adding to github issues: