Backlog, production push, sprints, schedules & updates

Firmware
1

Firstly, many thanks to the Spark guys for answering our queries extremely quickly on this forum.

When genuine bugs are found often it’s mentioned that these will be included in the next production push / update or that they are planned for the current / next sprint.

This got me thinking about how I know if the bug I’ve found has been corrected in the firmware that’s running on my spark core…

When the code is altered, does an OTA update of all of the cores happen automatically, or does each user need to initiate a flash of their sketch?

Where can we find the details of the backlog / release schedule and release notes?

Is there a software way of testing which release were on? A #define somewhere perhaps?

Many thanks.

2 Likes
2

Thanks @binaryfrost !
Updates made to the firmwares are first pushed to the master branch on the repository and then periodically to our compile servers. When one does an OTA, they get the latest updates from the compile server.

We release our sprint details through our blog channel: http://blog.spark.io/

To keep track of the bugs/issues, we use the guthib channel, e.g., https://github.com/spark/core-firmware/issues?direction=desc&sort=created&state=open

When major bugs are squashed, we also post it on the community and pin the thread to the top.

I like the idea of notifying the user about the release version on the web IDE everytime they compile/flash their code. I’ll propose this idea to the team.

Cheers!

3

Thanks @mohit, that’s really useful!

So, as users, what we really need to be aware of is when things move from the master branch to the compile servers, as that’s when these changes will be available / affect our sketches.

I’ll have a look at the blog channel and the github channel too.

Yep, knowing what we’re ‘sketching’ against in the web IDE would be great :smile:

Thanks again.

4

@mohit @zachary @zach @Dave

Looking at the github channel - do you want us raising issues/bugs there, or do you want us to raise things here, and for the :spark: experts to transfer relevant things there?

5

Hi @binaryfrost,

Hmm. I personally like github issues, but that would only cover certain kinds of bugs. Right now we’re working off an internal bug tracking system, so if you have a firmware, docs, etc kind of bug that clearly belongs to one of the repositories I think it’d be fine to create a github issue there and see how it goes. :slight_smile:

Thanks!
David

6

Yup @binaryfrost, in general I think the forum works better for extended group discussion, which can get frustrating in a github issue, obscuring the detailed technical discussion needed to solve the problem.

So if you find something you think is a bug but don’t fully understand, or if the problem involves the whole :spark: infrastructure (as opposed to one specific repo), or you just want to make sure we know about something you observed, this is the right place.

However, as @Dave said, if you have a well-documented issue with a test case and it clearly fits in one code repository, then opening a github issue within that repo is definitely a better way to get it on our radar.