OBEX with GITHUB (not OBEX vs. GITHUB)
LoopyByteloose
Posts: 12,537
OBEX is a useful resource, but it just doesn''t keep track of creative history.
On the other hand, GITHUB lets anyone inspired to extend software to fork existing code and move on. This is a huge boost in clarity about whence things came from and what projects are developing in parallal.
With OBEX you tend to get the bits and pieces, but are a lone developer when it comes to the challenges of a project
With GITHUB collaborating and contrasting tend to grow more and better code.
_____________________
Feel free to debate the pro and con. Personally, I think Parallax should adopt a more GITHUP CENTRIC approach to bolster more popular involvement with the Propeller and future Propellers.
On the other hand, GITHUB lets anyone inspired to extend software to fork existing code and move on. This is a huge boost in clarity about whence things came from and what projects are developing in parallal.
With OBEX you tend to get the bits and pieces, but are a lone developer when it comes to the challenges of a project
With GITHUB collaborating and contrasting tend to grow more and better code.
_____________________
Feel free to debate the pro and con. Personally, I think Parallax should adopt a more GITHUP CENTRIC approach to bolster more popular involvement with the Propeller and future Propellers.
Comments
The only value that OBEX gives really is a listing of code, some search capability, and novice users are not put off by it.
Have you actually used the git workflow?
So, for beginners, OBEX is the WTG for simple descriptions and downloads. Github I see as more for development.
So far OBEX is all about making available a bunch of off the shelf Spin objects that people can use to "bootstrap" their own projects. It provides all those "missing features" that people might expect from other MCU's: Serial Ports, SPI, PWM, etc etc etc.
Of course it has grown beyond providing such basic drivers to containing a huge array of other interesting functionality.
As such it's almost perfect as it is. Just fetch the object you like the look of, drop it into your Spin project and try it out.
For those new to programming or MCUs or Spin and the Propeller this is all great.
But users are developers too. Some of them want to donate their creations back to the cause. That's when a simple dumping ground for objects starts to look dumb.
Enter the ideas of source code control, version management, issue tracking, documentation wikis, collaborative development etc etc.
Which brings us to thoughts of Github. So far the best of such systems I have ever used. It's simple, it's quick, it's feature full.
But I can well imagine that is all a bit much for a beginner to understand. Or maybe they don't like git. Or maybe they just don't want to be bothered with or have time to take that on. It takes a bit of programming experience before you even start to appreciate why such a system is desirable.
Well, in short, we have users who just want to "load and go" and we have developers who want something more.
But hey, getting your development done on github or other SCM of choice does not preclude having an OBEX style location where people can just search for and fetch stuff.
OBEX itself could pull things from github. Why not?
As a minimum the end user may only be worried about released versions. E.g. I built my project with V0.0.1, now there is V0.0.2 in OBEX and my project fails with that, please keep all old versions available on OBEX.
With something like github at the back end this all becomes nice to manage. Some code in the OBEX server could query the github repo of an object and fetch the tagged released versions. The objects description in OBEX would come from the github repos README file and so on.
OBEX just become the interface to gihub at the backend. Users come in through the OBEX "front door". Developers come in through the github "tradesmans entrace".
Github has a nice feature where you can download a .zip of any revision (source), so there's no need to maintain a separate "OBEX" for the beginners. Simply provide download links on the Parallax website, and it goes straight to Github. Since you can point to a specific commit Parallax can have .zip downloads for current and past versions.
The general concept of revision control, and data management overall, is a bit more tough than just using files is, but not that much more tough when we think about all the ways we have to mess with files once we need revisions or history.
Github can offer up packages, binaries, etc...
A friendly OBEX front end, linking to things in Github would be pretty nice! Newbies can just "get latest" or "get stable", etc... and as they gain some skill, can make one more click, "View on Github" and start using the repository directly with a nice GUI client or command line.
If we took a step to organize under one directory name, everything we do could be fetched and used with few worries! Just needs us to think about the namespace rules for accepting OBEX code.
./obex/user/[name]
That's not quite enough, but you get the idea.
Mix in some tutorial videos showing the overall process, and it all could be really accessible to newbies, hobbyists and pros alike.
Recently, a higher end data management product I work with added Git integration for the purpose of unifying a mechanical bom, and related MCAD files, e-bom and related ECAD files, and software code, for what I consider a complete product definition these days. (documentation, graphics, labels, etc... generally do not need the complexity and just get woven into the product BOM as discrete files)
This gets further rolled up into a 150 percent BOM, which is basically all the product configurations, variations, and it gets fanned out as various MBOMS for manufacturing related things.
To do it right for a simple product, actually requires a lot of data! When we look at software, tooling, mechanical enclosures and supports, circuit board, components, labels, etc... can easily hit thousands of files, with hundreds for each unique revision!
Now, that doesn't have a lot to do with us and what we do here directly, but I really think some education emphasis in this direction would be very favorably aligned with industry trends in progress for a long time now, trends not always known because the software and processes aren't discussed much outside the larger companies, and they consider how they manage that proprietary.
I've been vocal about software being treated like EBOM, MBOM data is, and now it's starting to really happen! For a long time, it has been as software engineers have built and have been using revision control and data management for quite some time, and in ways often ahead of other industry disciplines. But now that we have nearly all significant high-tech product design companies employing this kind of software (PLM / PDM and variants), the idea of introducing students to it in this context is resonating more now than ever.
Perhaps one day we will see SBOMs out there as officially understood things like EBOM and MBOM data is now. A software bill of materials concept is basically the dependencies. A related BBOM, for the build system would complete the direct analogy to electrical and mechanical product representations and their engineering and manufacturing data needs.
So then, to simplify some, we could and should employ something like Github, or even host a repository at Parallax!
Doing the former is simple and accessible. Parallax can do it easily, and it's not hard for any of us to use. Where it is for somebody, we help them out and get their stuff into the OBEX.
But, if we did the latter?
We then could integrate the data management right into the tools, or an optional set of tools! It's not too much to make local clones of anything anybody wants, and those could be shipped with the installer as we do the sample code now, but the difference would be in how users both manage the code they write, share it, and get new code to make use of.
Just imagine running the tool, and it asks you for the name of your project, whether or not you want to host it locally or on the Parallax repository, and maybe another couple of details.
Project gets setup, when connected online, gets synced up with the Parallax repository, or some other one, whatever.
Then users go to author a new program. They click the "new" button, and the tool asks, "new what?" and they respond with whatever it is they are doing. Could be a C program, SPIN, some data typed into a text file, whatever they want! If they grab assets from their machine, pictures, sounds, binaries of various kinds, they add that as needed.
The tool keeps track of it all, and really they just need to know the names of things. Now, they would need path names for program references, but those could be some simple action away, or at the least, cut -n- paste.
This is a little more work than, say just creating files and writing them to a folder is, but the beauty of it comes just a bit later on.
Say they are about to build, or they have been building, but want to start a refactor, or some other fairly significant change. If it's to one file, they save a version of that file, tag it in some way, and continue building / changing. If it's to a lot of files, they could just "save all" creating a snapshot of the whole project!
If they touch a library, they use "make unique" and modify it to be something unique to their project, or they would make a revision to it that could be reviewed, checked in, and eventually update the OBEX.
Throughout, the system keeps history and revisions for them, only asking for those few bits of info it needs to keep 'em out of trouble. Big value add here, but also something of a change in thinking. --a change many MCAD users went through in the 90's, and it really paid off too. I'm sure it would here too.
One last concept:
Rule based builds. Once the system knows all that stuff, you can get it to do really neat things, like build with latest, build with working, build stable, and all the other little variations people need, and they just issue simple commands.
People using data management tools with history and revision control have been doing these kinds of things for a long time. Software and mechanical / electrical.
The key is to get it integrated and simplified so that even casual users can get the benefit. Perhaps that's too big of a jump, but a Github based repository as the back end of OBEX opens the door to all of it, and again, I suspect some work in education would yield some very valuable industry relevant training and a mind set people frequently don't get, until they are on the job, or well into higher education.
A newbie could just ask for stuff, or see lists of things they want. A pro could use the system from the command line, or via integrated or GUI client tools too.
IMHO, having this vision as part of "the Parallax Package" would add a huge amount of value, even when some of the more intense things I mentioned here are not done. Just the core, using Github or some other system frankly, as the back end adds a huge amount of value and potential to everybody involved.
Wouldn't take much for the basics.
Yes! And my long post above is some attempt to suggest why this is worth doing. Modern product design has already moved well into this territory, and it's moving down the chain rapidly. The experience people get and the mindset they have is relevant and increasingly valuable.
IMHO, what we really need is somebody to do what Chip is doing for the silicon. Take these pieces and weave them into one cohesive unit that works well. Leave that pro back door, right to the repository open of course, but provide a nice environment that works for education / hobby / small time product development too.
I think the OBEX is excellent at serving its purpose.
By not providing any peripherals, and espousing software-based ones in their place, Parallax needs to support this directly.
Why should Parallax give up the control, traffic, and potential sales that might bring to Github?
And, what percentage of OBEX objects ultimately are of an open source nature requireing such?
If I'm not mistaken, anyone can host a project on Github, so its a bit moot.
Its one thing to suggest features or changes one would like to see to the new Prop.
Not sure how Ken feels with the suggestion Parallax to give up parts of it business/support offerings.
It's a considerably bigger deal to package it all up with a browser interface. Still, they could do that.
Now, the OBEX code is MIT. Anybody could put it into Github, or some other system too.
Seems to me, the primary reason would be to augment it's business / support offerings. A managed environment adds a lot of value. Early on in the history of Github, that value was compelling enough for people to start asking them how to pay them so they would be sure the service was going to be around! They did that because having it done well added value to their own business.
That's the standard reason why.
Having the OBEX is a value add. It's not a direct source of revenue. To do that, the OBEX would have to be transactional, like a subscription, or cost per object, or some other kind of thing. Really, doing that wouldn't work well, unless Parallax was directly authoring code, or paying others for the right to distribute, etc...
As a value add, maximizing that value at an optimal cost is the real goal. When that's done, value perception is the highest while the cost of doing business and thus margin on the products is the highest / most competitive.
That said, either way is fine. Maybe they can do a better Github than Github does! Or maybe, doing something internal makes for better tool chain integration. One area I think is ripe for that sort of thing is documentation. Get that managed, online, and into the tools where it's always up to date, or can be synced to be up to date easily is a huge value add!
Most of what is in the OBEX was written by users, and it's MIT so that people who seek OBEX code for their own purposes can do so with no worries. Doing it with Github changes none of that really.
It just seems like this might be something someone could posit to Ken, versus trying to get the train rolling on a major change without their input.
Ken/Parallax may have no issue with it. However, they really need to have an assortment of tested peripherals that they support in their OBEX.
Personally, Github seems a bit much, but seems to work fine for PC projects which are normally quite a bit larger/involved.
With everything going on product-wise, not sure they have the resources to go ahead with this, assuming they do.
As Heater has so aptly pointed out.. This is NOT about elimination of OBEX, it is about enhancement of code resources so that larger projects on the Propeller and Propeller2 are publicly shared.
I have been working on porting Arduino 3D printer g-code controller code over to the Propeller recently and it just became very obvious to me that the Arduino community gains more project momentum out of GITHUB and sustains it.
Both resources working together would be a reasonable way forward with an awareness of where each leads. We already have Propeller C code libraries on GITHUB, such as Martin H.'s libPropelleruino. I suspect more GITHUB libraries for the Propeller C code are out there and the number is growing.
Why not have Spin and PASM projects on it with migration of OBEX duplicate downloads that are included in a project available there?
We have simply come to a point where many users are beyond the tedious Tutorial modality of solo learning and learn via collaboration in goals and projects that have wider vision.
In many cases, the learners don't have to even buy additional parts and build, they just contribute their intellectual assets and grow with the process. The eventual outcome is a proof that the Propeller can sustain real world applications.
Anyway using github does not make any difference. You see when you clone a git repo it has exacttly the same status as all the original and all the other clones. One can have in house repos and clones on github is what you do. They don't have to. The existing OBEX can stay exactly how and where it is. Only at the back end it can keep it's files in git repos. 100%.
It's a requirement of OBEX that al code is released under the MIT license. Quite so. In fact anyone could take all the objects from OBEX and stuff them into github today!
However using something like github creates a lot of goodwill among potential users and developers. No body is asking that here.
And if they were it may not be a bad thing. Back in the day the only programming language for the Prop was Spin and the only compiler contained in the Windows only closed source Spin Tool. Providing the opensource GCC and opening things up has only been good. As I said, these things create a lot of goowill feelings in t he community now a days.
The came git. I soon discovered that is so quick and easy to use for day to day code supervision that it's even beneficial when working on a one file program.
It don't have mess around saving files under different names as back ups incase my latest experimental changes don't work out. I can keep stuff on a server and clone it to any place i happen to and free time to work on something. All clones are equal remember. I can create experimental branches. I can tag the good versions. I can easily get a diff between where I am now and where I was then, to see what I broke;)
And then came github. Putting a shiny face on all that and making it even easier to use.
It's got to the point that when I want to write even the smallest program now the first thing I do is:
Exactly. A ton of headaches goes away.
An OBEX as a GITHUB front end would off load a lot of Parallax's information management headaches. A win-win winner for everyone, especially with the Propeller2 likely to create a burst of new contributions to code.
https://github.com/libpropeller/libpropeller
Are there simple commands for GIT that provide the same level of support as mercurial/code.google for development? I really like "hg pull, hg update someRevision, hg commit, etc...". What would be the equivalent for GIT?
github seems good for just getting the latest rev for sources, which is quite easy for newbies or those just wanting a project download, but does it provide what code.google does for developers?
Not saying GIT and github don't provide the needed support, just that it's not as evident to me as it is at code.google and with mercurial.
curious...
dgately
@Potatohead, What you describe regarding managing the tool chain was a practice in the telecom companies I worked for. All part of that concept (I think, been a while) that was all grouped under the concept of CMM. One company had migrated everything into ClearCase and that included everything involved in the build process, tools, libraries, compilers, scripts for packaging and builds, EVERYTHING. This gave us the ability to not only build a very controlled version of a product, but with the exact same set and version of tools, libraries and etc that were needed for that specific build. Major headache and surprise reductions were to be had from this process. There just seems to be a need to get a simple method for use by a smaller / single person shop to use. I had a bit of trouble /confusion the last time I tried to put together a local repo, but here we go again
Carry on with the discussion, of course, but understand that Parallax can't run a new effort for code management right now. One way or another, these things take time, money and opportunity cost.
Ken Gracey
I suppose that since OBEX is open source, I am simply at liberty to take a object or several objects and upload them to a project of my own making in GITHUB. And then just go from there.
Search engines would likely find the Project and it would be pretty much mirror the original OBEX for those few downloads. Since I am fooling around with Arduino code ported to GCC and then eventually revised to PASM, I could bring in Arduino .zip files to build on an meld the two with an eventual Propeller project as the outcome.
I think this might be more awkward to do in the OBEX settng. But I tend to be wrong at least 50% of the time.
Ken Gracey
Nonetheless, any project started does indeed require a commitment to seeing it through. GITHUB in some cases seems makes that commitment a bit easier to manage. As it is, I am just putting links in a Forum thread to whatever is required as it comes. I have to reread the whole thread to revise for accuracy and deal with a lot of distractions as people just appear and ask questions or comment.
Eventually the thread gets too long to be any good to a new user that wants to start a fresh project. There is just too much to read. And for the guy that started the thread, revision processes just get longer and longer. I think that Tackyon by Peter J has taken the one-thread approach to supporting a project to greater lengths than just about anyone else. But I suspect that is causes those that want to get started to be a bit shy.
I don't really see what value git brings to the table over mercurial. How do you handle merge conflicts in git for example?
-->The "change set" concept compartmentalizes things compared to a simple diff being done by whoever is resolving conflicts.
Actually, I'm wrong about that:
http://stackoverflow.com/questions/2475831/merging-hg-git-vs-svn
If you have an object to contribute, by all means put it in OBEX. If you can package it up nicely and don't intend to do anything more with it, then zip it up and attache it to OBEX. If it your Magnum Opus, you really like source management or you want the Wiki or whatever your favorite source management site offers, you can just put a like "offsite" in your description. I think you can embed a link, if not, that would be a minor change to let OBEX host Github, Google Code, Sourceforge, Pastebin, etc.
With something like this, then we can all just get along....
Another Kumbaya moment.......
But what if the original author disappears and somebody else wants to take up the improvements to the object? A big advantage to moving to VCS for the OBEX is that this is possible: it's not "your code" or "my code", it's "our code". Anybody can suggest and push improvements, without the original author needing to be in the loop.
You can't cheat death, taxes or loss of interest.
Without redoing OBEX (which is a non-starter), the only option is to try and ENCOURGE, COERCE, or otherwise have users contributing to the OBEX to voluntarily use an external provider. Put some text into the OBEX sign up/contribution page encouraging the use of community source control systems. It you find an object that is worthy but the author didn't think about their legacy, contact them and offer to move it to an external site.
The best you can do is to start a grass root effort to put things where the community thinks they should be.
(The following is not directed at anyone in particular but the community as a whole)
If someone happens to choose one provider, let's not see all the factions tell them they chose the wrong place and they should really move it to someone other place because of "X". Our tolerance levels seem to be decreasing lately. People have reasons for doing what they do. They are making a big gift of time and IP. Forumites shouldn't criticize because they used the wrong source management system, language or whatever else we are so quick to got riled up about. Potatohead's signature says it well, "Be excellent to one another."
The bickering is no longer fun....it's tiring even when done as good natured jesting. Having the only "right" solution is a claim that more and more peolpe are starting to have.
That's the way it works today no?
I suppose a reasonable enhancement for people who care for such things would be to post repository link information for collaboration. With feedback comments anyone could say ... here is a repository clone <include link blah> that fixes xyz bug. People can then choose the alternative version they like to use.
Merging is a big subject. I'm interested in a very small example like commit merging, which is typically the elementary basis for solving other issues like branch merging.
Given file quotes.txt in the repository:
That's a pretty simple example of course, but in a file that has 1000 lines and 20 changes, merging can be tediously difficult.
In mercurial, one selects the merge methodology with one of about 15 possible tools and/or methods that suit the user.
The simplest thing that can be done is is to turn on the merge conflict markers and resolve them by hand.
One does not constantly pull new clones in mercurial. Things can be fairly easily handled in the local repository.
That is:
This is worth a lot.
Been back in medical imaging service for a long time now, the above is merely an observation of the topic at hand which with care and feeding could devolve at some point to the next javascript thread.........