I don't care what you do or how you do it. IMHO, Parallax is the most OPEN company in the business. Please have the name of the repository reflect that fact.
Very good. All of the parties have arrived! Perry, I'll get in contact with you via e-mail. Daniel will get you connected with the Google tool, and we'll sit back and let you guys do what you do best.
I'm sure you have a good idea how much we appreciate this kind of support!
Ken Gracey
I'd like to contribute to this effort. Is there anything I can do to help?
I'd like to contribute to this effort. Is there anything I can do to help?
If it flies, I would be asking for folks to participate in review process.
Eventually we would want to review items submitted, but first we would have to devise and review (and agree on) the review criterion.
Its not a fast process, but VERY thorough, and great when it gets going.
Regarding use of space/network bandwidth, Git's over-the-wire protocol is extremely efficient, as is the disk storage mechanism. While an initial clone with Git might be a bit bigger, the full repository on a user's machine is rarely any bigger than the metadata-only for SVN. While TortoiseGit is nowhere near where TortoiseHg is, in terms of completeness/usability, GitExtensions is far beyond any other Windows-based source repository interface browser that I've seen. It includes extensions for Visual Studio, and there are Git extensions for Eclipse (EGit), NetBeans (NBGit), Vim (fuGitive), Emacs (vc-git), etc. Git also has the most complete command-line interface and documentation I've ever seen.
I think the biggest point in Git's favor, is actually Gerrit. While it can be a bit of a challenge to set up, it is extremely helpful in community projects such as this one. One anecdote is with the OpenOCD project. When they started using Gerrit, the contribution/commit rate was five times what is was before with patches being mailed back to the maintainers, and that's within the first month.
I am confused on how this will work. Lets take an object that reads a sensor, ADC for example. It will be in one of the 20-30 zip files in download. It uses the SPI object and the demo program uses Full Duplex Serial. Will the ADC object, demo program and the two support objects be all zipped into and archive in the download zip file? If the SPI object is updated, who will or will anyone update it in the various download zip files?
Google Code has a download tab and a source tab. Is it envisioned that the download tab will have a small(er) selection of objects/programs and the majority of what is now in the OBEX will be in the source tab?
John Abshier
Hey John -
As I see it right now, the Source tab would be used to evolve the core objects to be more Gold Standard Compliant. In the example you cited, we'd have Full Duplex Serial and SPI in the Source area. To deliver the application example you cited with the ADC, the latest versions of Full Duplex Serial, SPI, an ADC object would be zipped into an archive as they existed in their demo and moved to Downloads. The Wiki component would be used to categorize and library what is in the Downloads tab.
So, I think that the core objects from OBEX (the lower level ones) would reside in the Source tab, but also live in a zip in Downloads. There's a manual component that cannot be escaped. Because no tool is perfect (including OBEX) it also has a human component required to make it function properly. And we have been unable to provide that full-time person to make it go. Even if we could, they'd be a user rather than a coder so they'd be stuck with the framework provided, at the whims of a programmer who is not only unavailable but coded the system in a way few of us could pick it up.
But this is up for discussion before implementation. As you know very well from your question, things can get messy really fast. I'm hoping that the team of four we assemble can make the right decisions together about how to approach these questions. I'd be very happy to have some kind of super-tool right now that isn't tied to a specific developer designed around their own preferences, so we're looking for a commonly-accepted, somewhat universal tool that's known by our customers and can be configured off-the-shelf.
This is a test, only a test, until it becomes official.
#1 - google repository ok, but this is way easy to duplicate and have complete ownership/control. Why bother with google? You would have better search than obex, though. Does this repository allow for comments/reviews?
#2 - Why don't you have online code search/updates built into your prop IDEs? You can search, see the review and have it autodownload into your library!!??? (Competitive advantage!)
#3 - Have a beginners page where you have a web page outline of various types of objects and can obtain specific libraries (see www.arduino.cc)
I agree with number 3 especially. We'll make that happen.
#2 - that's a goal here as well. We'd like our Parallax distributions (through Propeller Tool, SIDE, etc.) to draw upon a single source.
I have always considered the objects that come with the Propeller tool a "standard" to go by and the OBEX for custom individually made programs. I am a very lazy coder and that is why I like spin /pasm so much. I think the OBEX maybe with some basic rules such as simple explanations of methods, constants, variables and program use and a group of forum members to go over submissions to make sure they comply with these simple rules before they are allowed in the OBEX.
As far as checking the code of each submission, do not. It is up to the end user to align it for their own use. Keep the GSL or Google code repository for the new standards you are putting forward. Just my 2 cents.
Comments
Rich
Couldn't agree more. The standard objects have improvements and these need to be incorporated before we get to gold standards.
Absolutely required!
If it's not easy to find and simple to download then it will not work for the target audience.
If it's not easy to upload to, modify and upload to, etc, then likelwise, it will not work for the majority (me included).
Summary... KISS
If it flies, I would be asking for folks to participate in review process.
Eventually we would want to review items submitted, but first we would have to devise and review (and agree on) the review criterion.
Its not a fast process, but VERY thorough, and great when it gets going.
I think the biggest point in Git's favor, is actually Gerrit. While it can be a bit of a challenge to set up, it is extremely helpful in community projects such as this one. One anecdote is with the OpenOCD project. When they started using Gerrit, the contribution/commit rate was five times what is was before with patches being mailed back to the maintainers, and that's within the first month.
Hey John -
As I see it right now, the Source tab would be used to evolve the core objects to be more Gold Standard Compliant. In the example you cited, we'd have Full Duplex Serial and SPI in the Source area. To deliver the application example you cited with the ADC, the latest versions of Full Duplex Serial, SPI, an ADC object would be zipped into an archive as they existed in their demo and moved to Downloads. The Wiki component would be used to categorize and library what is in the Downloads tab.
So, I think that the core objects from OBEX (the lower level ones) would reside in the Source tab, but also live in a zip in Downloads. There's a manual component that cannot be escaped. Because no tool is perfect (including OBEX) it also has a human component required to make it function properly. And we have been unable to provide that full-time person to make it go. Even if we could, they'd be a user rather than a coder so they'd be stuck with the framework provided, at the whims of a programmer who is not only unavailable but coded the system in a way few of us could pick it up.
But this is up for discussion before implementation. As you know very well from your question, things can get messy really fast. I'm hoping that the team of four we assemble can make the right decisions together about how to approach these questions. I'd be very happy to have some kind of super-tool right now that isn't tied to a specific developer designed around their own preferences, so we're looking for a commonly-accepted, somewhat universal tool that's known by our customers and can be configured off-the-shelf.
This is a test, only a test, until it becomes official.
- Ken
I agree with number 3 especially. We'll make that happen.
#2 - that's a goal here as well. We'd like our Parallax distributions (through Propeller Tool, SIDE, etc.) to draw upon a single source.
- Ken
As far as checking the code of each submission, do not. It is up to the end user to align it for their own use. Keep the GSL or Google code repository for the new standards you are putting forward. Just my 2 cents.