I totally understand your perspective, and if it was posted I still could choose not to look to keep motivated (if that’s the way I roll)… however it sure would be hard not to look.
That said, with the number of times I’ve seen someone say “added to the backlog” … I think it would be a bit scary to see this massive list! I know how I feel when looking at my own project schedules… like, uhg… sigh… moan.
A view of the next couple weeks out might be good compromise though…
I’m also thinking about all of the people that see this list that won’t contribute to it other than asking if something is done yet, or if it could be bumped up. It could also generate ideas that haven’t been thought of yet.
It would broaden the term Open Source/Open Hardware to more of like an Open Company. Tricky.
well Spark is a company working in Open Hardware/Software and basically we are giving work hours away for free because we enjoy it, want to have a better tool or just doesn’t have any better way to spend a Saturday evening. So with that in perspective I think the Open Company that you suggest is more then right to ask for. Spark is gaining tremendous amount of work hours from us and sure we are getting a tool to play with but it is a tool that we pay for and that should work as advertised. So asking for Spark to share what they are working on so that we dont do double work is the least thing I think we should ask for.
Regarding people not contributing but just asking when things are done I think that is valuable input also. Helps Spark prioritize what the community wants and as you say think of new functionalities etc.
Each one of us reads and posts on the forums almost every day, I don’t think we’re going to secretly work on something in a public repo and not tell somebody if efforts are overlapping. There have actually been a few cases of the opposite happening on the forums. Where people wanted to start on libraries / features, and checked with us to make sure we weren’t doubling efforts.
I think the reasoning behind sharing / not sharing the list has everything to do with the extra work involved in maintaining and publishing something official. I really like the idea of sharing what we’re working on, but I suspect people might be upset if tasks were missed, or if we spent our time building a feature / fixing a particular bug when someone else would have preferred something different.
I’m happy to share what I’m working on this sprint (if anyone cares… ):
My Sprint:
Work on the command line utility to flash and register public keys, register and claim cores, compile and flash firmware, and have basic serial, variable, and function behaviors. If the firmware is ready and I have time, also adding switch server behaviors. I also hope to groom the repo to be open-sourced (add licenses, etc).
Work on the build farm to improve reporting, and other necessary maintenance
Work on the cloud to detect and report slow round trip calls
Work on the cloud to improve PUT source to flash via the API
Start work on the cloud magic opt-in firmware upgrading process
Start work on other new protocol features and improvements
I’m also processing and helping repair returned cores
I also have a great big list of lots of little bug fixes and improvements that I want to get to.
@Dave I guess it goes in both ways with people (at least me) is annoyed when you are not sharing. That said it is your project and Im just trying to work with it and buying boards (~60 so far) so feel free to do whatever you want, not like I can force you in any way.
I need some coffee and I should probably stop rambling here.
edit: to remove my stupid request of not seeing who is admin here, you are yellow…
@sjunnesson To be honest we would love to find a way to share our priorities and upcoming tasks - however as @BDub said in his post, the list is extremely long, and our priorities are constantly shifting. Also, we use Asana for task management, and they don’t provide a mechanism for sharing a public list. We’ve thought about using Trello to provide a public list, but then we have to manage tasks in two different places, which is a lot of overhead; we do want to be public about what we do, but we also don’t want to spend all of our time sharing and less of our time building
In any case I definitely appreciate the feedback, and tonight when I write the blog post closing out Sprint 5, I’ll be sure to include the priorities for Sprint 6, which include:
Lots of improvements and fixes to our documentation, including creating a “getting started” screencast
Delivering a Command Line Interface (CLI)
Starting on a mechanism for sharing community-generated libraries within the IDE
Various IDE bug fixes
Spark.publish() (formerly known as Spark.event())
Debugging CFOD
Various Core firmware bug fixes (mostly relating to connectivity)
Please be constructive, @sanwin. As I mentioned, debugging CFOD is on our list of top priorities, and we are working with Texas Instruments on low-level debugging on the CC3000 firmware, as has been discussed on other threads.
I’m just a little frustrated because the core is still not working properly for extra-simple examples like led-blinking.
Today for example it still “Breathing cyan”, but led D7 stops, looks like core is frozen. Flash from web doesn’t work, after restart core working again.
Absolutely understood; we’re frustrated too, and wishing we had more control over the entire stack. The CC3000 is unfortunately somewhat of a black box for us, but now we’re getting the support we need from TI to resolve the issues - just at their pace, rather than ours
sanwin, I was (and am still) using an Adafruit CC3000 breakout with a teensy 3 when I was waiting to receive my Spark Cores and they are having problems as well. From working on their forum, I can tell you that the Spark Team is WAY more into TI’s face regarding this problem than Adafruit. With both teams pounding on TI, a solution WILL be found. Be patient young padiwan
@sanwin, please post the code that you were using when D7 stopped but your RGB was still breathing CYAN. That typically sounds like when the user code is stuck in a tight loop. While there are problems with the Spark Core right now, MOST of my problems with it have been my own coding mistakes... and I dare to say, I'm a prefectionist. yeah I mis-typed that on purpose... learning to let go!
If you could build code locally, you could also try out some watchdog timer code we're working on that aims to help automatically reset your core for you when your user code goes into a tight while loop, then alerts you currently with a different breathing LED color that something went wrong and a watchdog timeout occurred. You can follow along here:
I think it’s useless to say but my core also goes “offline” after random amount of time from 30mins to 7-8hours. I tried to eliminate delays, but even if there is no delay it just freezes.
Wishing best of luck with TI @zach, looking forward to a solution! Keep up good work!
There have actually been a few cases of the opposite happening on the forums. Where people wanted to start on libraries / features, and checked with us to make sure we weren’t doubling efforts.
yeah I mis-typed that on purpose... learning to let go!