PropSource: one-stop code repository http://code.google.com/p/propsource/
Ken Gracey
Posts: 7,400
Hey there,
We want to build a one-stop, clean code repository using existing Google Code tools. Allow me climb out to this thin limb to propose something our community needs to resolve. We need your help to do this - you ask us to call upon you for help, so here we are!
You're familiar with the struggles we've handed our customers with distributing Spin/ASM Propeller code. First off, our code is available nearly everywhere: forums, OBEX, Propeller Tool distribution, the internet, Help files, web site, product pages, etc. Duplicates exist and sometimes code may be posted in one place but not another. Add in the growing Simple IDE and that it also needs to be distributed with code. We have trouble keeping track of it ourselves.
You're also familiar with our Gold Standard Library (GSL) concept http://www.parallaxsemiconductor.com/support/goldstandard, which aims to release high-quality code examples especially for core objects we use all the time. And you're aware of the fact that we've not done much with the GSL. The challenges we've had with releasing GSL-approved objects include the one-way gatekeeper being Parallax (community should be able to approve), no revision control, and no solid [internal] follow-through plan to include approved GSL objects in our Propeller Tool / SIDE distributions. Perry (post 54 at http://forums.parallax.com/showthread.php?141224-Gold-Standard-Library/page3) identifies several of our problems with OBEX as well as a solution.
New users also can't find most everything they need in one place.
We would test a new community-driven code repository at http://code.google.com/p/propsource/ with simple goals:
The Source section would let us evolve, track, and commit the core objects (GSL) that need improvement as they make their way into a zip in Downloads. For example we would initially post keyboard, mouse, TV, VGA, synth, clock, debug, and Parallax Serial Terminal Spin objects here for improvement. As these objects mature they are blended into the appropriate zip and moved to Downloads.
Downloads would include zips of useful code libraries, tools and their demos (some of which are from Source):
This is only a starting point - our actual solution could vary a bit as we need it to.
If PropSource is accepted by the community:
It's pretty basic http://code.google.com/ but it helps to know a little about it in order to use it. It's useful for both users and developers. For users, the Downloads section provides a one-stop place to get code. Developers may spend more time in the Wiki, Issues and Source sections. You have seen it productively used for PropGCC and Simple IDE, which would remain where they are today at http://code.google.com/p/propgcc/ and http://code.google.com/p/propside/.
Project members can be given one of three roles: Owner, Committer, or Contributor. Users who are not members are also able to view project content, report issues, and leave comments. Users who are not signed in are limited to viewing content only.
So we're going to try this out. We're posting stuff here and we are going to see if you use it.
We need to act. Custom-developed solutions are out of the question. And we're looking for support. The above theme can be modified and is just a starting point.
Who can we recruit as a Committer? Pedward? Others? We can provide small financial incentives, loads of free hardware, and the internet currency we all enjoy (recognition).
If you are interested, please contact me via e-mail.
Thank you,
Ken Gracey
We want to build a one-stop, clean code repository using existing Google Code tools. Allow me climb out to this thin limb to propose something our community needs to resolve. We need your help to do this - you ask us to call upon you for help, so here we are!
You're familiar with the struggles we've handed our customers with distributing Spin/ASM Propeller code. First off, our code is available nearly everywhere: forums, OBEX, Propeller Tool distribution, the internet, Help files, web site, product pages, etc. Duplicates exist and sometimes code may be posted in one place but not another. Add in the growing Simple IDE and that it also needs to be distributed with code. We have trouble keeping track of it ourselves.
You're also familiar with our Gold Standard Library (GSL) concept http://www.parallaxsemiconductor.com/support/goldstandard, which aims to release high-quality code examples especially for core objects we use all the time. And you're aware of the fact that we've not done much with the GSL. The challenges we've had with releasing GSL-approved objects include the one-way gatekeeper being Parallax (community should be able to approve), no revision control, and no solid [internal] follow-through plan to include approved GSL objects in our Propeller Tool / SIDE distributions. Perry (post 54 at http://forums.parallax.com/showthread.php?141224-Gold-Standard-Library/page3) identifies several of our problems with OBEX as well as a solution.
New users also can't find most everything they need in one place.
We would test a new community-driven code repository at http://code.google.com/p/propsource/ with simple goals:
- Develop a single repository where the most important and useful Propeller Spin/ASM code may evolve and be distributed, under community control.
- Support 3-5 Committers who can be gatekeepers, holding a high standard on behalf of all Propeller Contributors (Parallax would retain the Owner role). Committers would also approve Contributors and assign various roles/permissions.
- Use the Gold Standard Library as a guide to provide quality code, but not as a techno-oppressive tool that prevents people from submitting code because of minor differences in the best way to author code.
The Source section would let us evolve, track, and commit the core objects (GSL) that need improvement as they make their way into a zip in Downloads. For example we would initially post keyboard, mouse, TV, VGA, synth, clock, debug, and Parallax Serial Terminal Spin objects here for improvement. As these objects mature they are blended into the appropriate zip and moved to Downloads.
Downloads would include zips of useful code libraries, tools and their demos (some of which are from Source):
- Propeller Tool
- Application Notes and Code
- Parallax Product Code
- PE Kit PDFs and Code
- Learn.parallax.com Code
- Propeller Code Libraries (maybe individual zips of objects for communication, human interface, sensors, A/D, etc.)
This is only a starting point - our actual solution could vary a bit as we need it to.
If PropSource is accepted by the community:
- http://code.google.com/p/propsource/ becomes the main repository for all code and tools that flow from Parallax and Contributors. We all start pointing to one place for code. There will always be exceptions.
- OBEX would eventually go into an archived state of deep sleep (honestly, we can't maintain that beast anymore - the code base is from a single developer and we're attempting to mimic web tools that do this nicely already, not to mention we don't review all submittals). We'd ask people to move their best work over to PropSource.
- PropGCC and Simple IDE stay on their own Google Code sites, where they happily grow.
It's pretty basic http://code.google.com/ but it helps to know a little about it in order to use it. It's useful for both users and developers. For users, the Downloads section provides a one-stop place to get code. Developers may spend more time in the Wiki, Issues and Source sections. You have seen it productively used for PropGCC and Simple IDE, which would remain where they are today at http://code.google.com/p/propgcc/ and http://code.google.com/p/propside/.
Project members can be given one of three roles: Owner, Committer, or Contributor. Users who are not members are also able to view project content, report issues, and leave comments. Users who are not signed in are limited to viewing content only.
So we're going to try this out. We're posting stuff here and we are going to see if you use it.
We need to act. Custom-developed solutions are out of the question. And we're looking for support. The above theme can be modified and is just a starting point.
Who can we recruit as a Committer? Pedward? Others? We can provide small financial incentives, loads of free hardware, and the internet currency we all enjoy (recognition).
If you are interested, please contact me via e-mail.
Thank you,
Ken Gracey
Comments
Hey David - this is only for Spin code. Propeller C would continue to live on the PropGCC forum where it is happily existing on its own.
Got your other e-mails and hope to reply soon. Between DEFCON and some travel I have had no time.
Ken Gracey
Would this new approach then also permit a way to submit code that is NOT MIT licensed?
I have not contributed my multi-tasking operating system and the various related multi-threaded drivers (one cog does numerous functions "simultaneously") to the OBEX because I do not want unrestricted commercial use of my efforts without some compensation from the beneficiaries. And hence MIT licenses does not meet my requirements, yet I DO want to benefit from the distribution channel offered through a Parallax steered facility.
So, might this now be possible ??
Cheers,
Peter (pjv)
Looks like the ideal tool to install for reasons you cited. We agree.
Peter, sure - why not...it's time to see your RTOS for Propeller!
Enjoy!
Mike
Of course you're free to do what ever you like regardless
- I dont like Parallax loosing control of the source/objects.
- I dont like Google or any other public site because they bombard you with
- The type of repositories are *nix style command based and complex for us
I understand that OBEX is a problem for Parallax to support. However, it isads (and often spam too).
windoze users.
still quite simple for anyone to use. There are no commands to learn, etc.
While I am an experienced programmer and windows user, my *nix use is
virtually nil, as is C. I dont see the point in going backwards to support a
*nix type of system.
All those repositories are a PITA to
use. You never know if you have obtained the latest, or all, of what you are
after. It is just too complex for us simple windows users we have been spoon
fed for too long! I would rather pay for my legal windows licence (and do) than
a free *nix platform.
I do however, respect that others have different opinions. That is why I
believe Parallax had to support C on the Propeller.
But I would hate to see the *nix gurus push all the sources onto a complex
*nix styled system and leave us simple windows users, which includes a lot of
newbies, out in the cold simply because it is too difficult for us/them.
We all know that a lot of us just dont take the time and effort to put
some of our code up on OBEX. Imagine how much is not going to be put up on the
google code site just because it is even more difficult to do.
Just my 2 cents
Edit: I just checked and it seems they decided to use Subversion (SVN) with PropSource however the same comments apply. There is a Subversion plug-in for Windows Explorer that makes it quite easy to use.
-Tor
-Tor
Thanks, bye!
And SimpleIDE gets ever more bloated and un-simple:)
Give me "git clone bla bla" from the command line and it's done.
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
This is brilliant. This is going to get crazy-large quickly, according to the degree of success.
Before I send my email, I'd like to preface with a discussion the "others" part.
I'm a Software Quality Engineer, focus is requirements traceablilty and Process. These skills are usually applied to very large critical systems projects, but can also be applied to very small non critical projects. Just as a blue print or plan helps when building a sky-scraper, the same also helps when building a bird house. In both cases success depends on sufficient planning, even thought the degree of formality varies.
I put forth that clearly defined and easily understood PROCESS is key to success on any large (greater than three to seven people) project. In this context, process is used to define the interfaces between individuals (community developers and parallax employees) and infrastructure elements (the code submission process, the google code repository, etc)
As a process guy, I advise that the processes be defined with the absolute minimum rules, closer to zero is best. Only make and apply a rule when a specific conflict is to be resolved. Defining process is not hard, but is not quick. It has to evolve based on the users needs, and the way the infrastructure meets users' needs. At least one individual has to "own" oversight of "process" in order to keep it usable.
As cited previously, the interaction between community members and the tools can be source of problems. This is solved by process, and training. Success in will depend on the degree to which the targeted users can understand and use the processes for using this proposed infrastructure.
Does anyone have an opinion, is any of this necessary or useful here?
Put it all in there, or none of it. If this repository for "gold" is to be created, include the docs, software, everything needed to play, starting from "I have a supported computer, USB cable, Demo Board" and go from there. First step is to just put it all there and document the process to get started. Second and future steps then are to refine it to deal with the list above. Commit, in other words. None of this get one piece from parallax.com, another from the repository, and some final bits from the forum, or other places.
The only things that shouldn't be in there are those things that can't be there for legal reasons, or stuff that the community is building on and that's just an ordinary activity to be incorporated if it starts to really show resonance and value worth doing the work to incorporate proper.
BTW: If there is doubt about fully committing to a repository, the effort will fail. Resolve this completely, then commit, then build, or do nothing as what we've got is fine. (Not fine really, but without a commit, the new effort won't add enough value, IMHO)
Edit: Long post, sorry. The reason why it all needs to go in there is the body of code we've got that's "gold" or "reference" isn't too compelling compared to the bodies of code we've got everywhere else. By centralizing general access to software distributions, or links to distributions I suppose, documents, and this golden repository, there is a reason to visit, and focus comes from that. Somebody shares one link, and it's there, inclusive. Go from nothing to writing a program from that place, and of course the process is there, documented and is the first thing they see.
There is actually very little risk of losing control of the sources. Besides, everyone here who wants to participate will have a copy. This also makes the cloud library idea possible - ready Phil?
A nice option for command line averse folk is http://tortoisesvn.net/ I've used tortoisehg which is pretty good especially for showing diffs, etc.... Command line is still better for automation and huge changes to the repo.
Thank you for the replies so far. I have detailed responses from:
SRLM
prof_braino
Haven't heard from pedward. However, provided pedward can join the team I'd be very happy getting started with these three guys in some control on our behalf (SRLM, prof_braino and pedward).
What I'd like to do is throw Daniel Harris in the mix on behalf of Parallax as an Owner, and then make the three guys above Committers (or whatever is determined appropriate). Daniel would herd the cats from this point forward - my role would be more limited (as a cheerleader, and to make sure we've got some incentives in place) but Daniel would be the person mostly speaking on our behalf. He might want to change the name to SpinSource.
I need to hear from pedward so we can move forward. - Ken
I would be happy to be a contributor as necessary as time permits.
However, I do not want ANY role as a decision maker or a code reviewer.
One thing that can be done to preserve the integrity of the source is to get IT to make a weekly backup of the repository. Command line tools can be easily set up to run as a cron job by IT on a server.
Thanks,
--Steve
I'll eat my own dogfood and participate as a Commiter.
I agree that initially we should focus on keeping things simple. The biggest headache thus far has been agreeing on a "standard" library of supported peripheral objects.
The GSL lays out a good premise. I think it's more important to get a living set of "standard" objects out there.
I suggested SVN as the VCS for a variety of reasons. First, SVN doesn't maintain anything but metadata on the client, so it's lightweight and not bandwidth intensive for clones. SVN is relatively simple to manage, especially if you utilize the well designed plugins for IDEs such as Eclipse. For Windows, Tortoise SVN is an excellent explorer shell integrated tool that makes it easy. Managing contributions, branching, and merging can take a little effort, but it's not nearly as complicated as Hg when things don't go right. KISS is important for success and SVN is as complicated and simple as it needs to be. Git and Hg maintain clones of the entire repository on local machines, which can be very bandwidth and space intensive. As long as developers work compartamentally and ensure they are up to date before making changes, few conflicts will occur. Like with other VCSes the committer is responsible for conflict resolution. SVN does a reasonable job of merging changes automatically, so real conflicts only occur when major code changes are made.
In my daily job I use SVN to manage development, releases, and branching. In practice Tags are used for static releases, Branches are used for development, and Trunk is used for the main codeline. It's important to get a standard layout nailed down first to avoid refactoring and history hiccups. It's important that any codeline can be traced back to revision 1.
I'm sure you have a good idea how much we appreciate this kind of support!
Ken Gracey
#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)