Tuesday September 7, 2010
Good morning,
leaflabsandy, I am sorry you feel frustrated. From your recent questions, answers, and comments on the leaflabs forums I suspect you have made useful contributions to other hardware/software forums and other open source projects. Being an active member of an open source project is very new to me. Once, I sent a suggestion to an open source software project and to my amazement the feature was added to the next release!
Yes, having a bug list (with detailed descriptions and priorities) would be very useful. I would add "bug status" to your wish list of features for a bug list. I like your request for an easy to find "to do" list. Personally, I use "to do" lists to keep my projects on schedule, but I also find them great for helping me see what and when tasks were accomplished. I do not delete items from the list. Completed tasks are simply marked as done (and dated) which allows me to refer back to them in the future.
However, as in all organizations, keeping "to do" documentations (both internal as well as public) up-to-date is a challenge. I suspect the leafabs team wishes for longer days. When I am coding or debugging code twenty-four hour days are never long enough.
Is it more useful for the leaflabs administrators to spend their time debugging code or updating documentation and "to do" lists? What about the long hours (I hope) being invested in developing Maple native? I do not know how often the leaflabs group meets (or even if the entire group meets in person or simply online) to discuss current problems/assignments/priorities. I do not know the size of the leaflabs team, but I suspect each member of the group wears different hats on different days. I do not know if bnewbold is the primary team member who dedicates a significant amount of time to web site development/maintenance (note: I would suggest adding a "Site Map" to the leaflabs web site).
leaflabsandy, I share your disappointment, but mine is tempered by enthusiasm for the Maple project.
Last week I began to work my way through the libmaple source code. I was very interested in looking at the changes made to SerialUSB(), because during the last few weeks different users have reported problems related to this function. Based on the github dates, the file with SerialUSB() had not been updated for a while. Initially, the old file dates surprised me since I thought changes were still being done to SerialUSB(), but then I realized changes might be made to the various low level interrupt functions supporting SerialUSB().
Today, I was very surprised when I read on the forums that a partial solution to SerialUSB() problems was found several months ago. I thought the warning on the SerialUSB() documentation about DTR/RTS (data terminal ready/ready to send?) was just a temporary suggestion to help coders with a work-around. I had assumed a more robust SerialUSB() was still in the works and that future documentation would include more OS specific examples and tips about using getDTR() and getRTS() (not just "You may need to experiment with the DTR/RTS logic for your platform and device configuration").
It is possible the DTR/RTS warning is not related to my SerialUSB() problems and that someone at leaflabs is still trying to replicate my problems. However, a tracking system would allow users to know if a bug report was closed (and was not receiving any active attention).
I do not know when the Arduino project started, or how long it took the project to reach "critical mass" (which I hope the leaflabs project achieves soon), but the Arduino "news archives" started in the summer of 2005. That puts the project at at least five years old.
There is a separate section on the Arduino forum where users can describe bugs and make suggestions: http://www.arduino.cc/cgi-bin/yabb2/YaBB.pl?board=swbugs Recent posts to the Arduino.cc bug forum relate to sizeof() problems. If the Arduino project is still having problems with sizeof() after five years I think the leaflabs group has done well so far. If I am correct, it has been less than a year since the Maple was upgraded to a four-layer board.
I do not know the typical size of open source projects. The size of open source hardware projects is probably different than open source software projects. I do not know how many "full time" coders are on a typical open source project. leaflabsandy, remember, in their responses to comments and questions several leaflabs administrators have stated they have day jobs.
Yes, I am often disappointed by the Maple documentation (which is improving every week), but I think the leaflabs team has done a great job so far both on the hardware and the software.
In a perfect world we would concern ourselves only with the bugs in our own code, but with open source projects it is often confusing why it seems to take a long time to solve "critical" bugs.
leaflabsandy, I hope your weekend experiences did not break your enthusiasm for the Maple project. If you post your code which shows problem in the maximum serial baud rate, millis(), and word() the bugs in the functions can be fixed and the code can be use to test all future releases of the libmaple.
Contributions encourage better open source projects. I think it was my long lists of spelling and grammar mistakes which convinced the leaflab team to use aspell to check for errors.
I am looking forward to the Maple-IDE 0.0.7 software release!
Thanks!
Stephen from NYC
