Michael Aivaliotis

@Jim Kring, it seems to me that the export of the code has gotten a positive response from the community. However I may be wrong. If anyone has any opinion either way, please come forward. As you can see in this thread, it appears the community has rallied around this effort. This is why I emailed you to come here and share your thoughts. In the past, OpenG was a great venue to showcase how a bunch of passionate LabVIEW users can come together and collaborate on something useful. The passion is clearly still there, as shown by the numerous discussions here. The general coding community has moved to Git with GiHub being the hub. This seems like the logical next step. Who knows what this initiative will lead to. However, I’m expecting that placing OpenG in a neutral GitHub repo will provide the spark and the tools to facilitate open collaboration, then the community can drive the future. The community is full of smart people who have a desire for clean tested code. And if issues come up, LAVA discussions (or GitHub issues) are there to hash things out. When LAVA offered to host all OpenG discussions back in 2011. it was clear that the community wanted to help. When @jgcode put his standards together for how code should be discussed at that time, It was an exciting time. Since then, many people have come forward with offers to add new code into OpenG and fix bugs. For example @drjdpowell first offered to include his awesome SQLite toolkit for inclusion into OpenG. He got no response either way. It’s a shame to have a platform and forums to allow people to post and discuss OpenG code and then ignore it. If you have ideas on what the future of OpenG is. I’m hoping it’s to be more transparent and inclusive. Providing the tools, resources and some safety checks along the way, is the best way to facilitate passionate individuals to dive in. Do you think keeping the status quo of the past 10 years makes sense? It seems to me that the community disagrees. What do you think?

I can see why you asked that question. It seemed to come out of left field. The intent is not to fork OpenG or create a separate development branch. The intent is to facilitate community involvement and incorporate some of the ideas floating around here on LAVA into new future builds of OpenG. JKI has taken some of the libraries, not most. I counted 5 on JKI and there are around 23 that I found and migrated. Granted, some of them could possibly be merged into new or cleaned up. However, this can be decided by the community. I think having a location that the OpenG community can call their own is important. Including documentation on how to contribute and providing an open, inclusive, transparent development and deploy process is part of it. Having them on GCentral was my idea. I didn't get official approval from GCentral. I've since moved (and renamed) the repos from where I had them to a dedicated OpenG organization. This way it would truly be separate. If you want me to add you as a maintainer, let me know. If there are any contributions to OpenG that JKI has made on the JKI branch, we should merge them into the new repos. New location: https://github.com/Open-G

I'm glad to hear that you are welcoming to this. I think this initiative and the positive response shows that the community is willing to take on some of these tasks and responsibilities as long as there's an open and inclusive process in place. As a starter, it would be great to revive the openg.org domain which has been dead for many years and at least point it to the LAVA OpenG root forums,. That's where it was pointing to before as indicated by this post. In the future, it could point to a GitHub landing page.

It seems like OpenG needs a landing page. Perhaps if we use GitHub Pages for the GitHub repos, as proposed here. This could be the new URL to include in licensing.

I agree.

Cool. I'll look into it.

Good points. You can't create a wiki for an organization. I've setup an OpenG team, but even there, no wiki support. Limitations... However, each repo has its own wiki. Which is good for content related to that specific repo. It's possible now with separate repos, to have each one have it's own LV version and build/release process if needed. However, if not, then each wiki can simply have a link to some global page that covers the overarching policies. This could be on LAVA, but I think the LabVIEW Wiki could provide support here. There could be a single page there covering everything, which is also community editable. Creating issues can be done by anyone. So if you want to do that, go for it. If they are invalid, they can be closed later. We should also search here son LAVA and create issues for stuff reported by people in the past.

NI does (Stephen Mercer) not recommend using them pre-official release version.

I wanted to do a live video stream to discuss the topic of collaborating on OpenG code on GitHub. I realize that this can be a very long discussion going in many different directions. But for now, I just wanted to keep it simple to the basics of GIT and GitHub. There could be more livestream discussions later about any topic. But just wanted to gauge interest and see what the community thought. I wanted to make this a livestream because it would allow you to ask a realtime questions and it would help focus the info on stuff you are interested in.

I've migrated most of the code to Github.

I turned it off.

Sort of. I think Github uses the email address, not the username. I've asked @Rolf Kalbermatter for his GitHub email, because it didn't work with his username. I decided to leave the repos under GCentral and use the OpenG prefix as suggested.

I've started adding repos: https://github.com/Open-G

@LogMAN, Is it possible to remap a source forge username to a GitHub username?

Can you describe the workflow? This doesn't seem to be a good solution on first blush.

@Rolf Kalbermatter, I will be redoing the export today based on the new scripts, if they work. So if you committed code recently, it will get included. I think you are the only one working on any code at the moment. I will add you as a collaborator on the repo so you don't need to fork. Once the conversion is complete: Make a branch on the git repo. Checkout the branch Do a file diff between your local SVN and the Git branch. Copy over the changed code from SVN to Git. Commit the branch. @LogMAN, unfortunately GitHub does not have a good way to group related repositories, so they visually seem to belong together. The only distinction is organizations. There's the Project feature, which I think just helps with development workflows. Having numerous OpenG repositories will make this a bit messy. But I guess there's no way around that. It seems GitLab and Bitbucket have a slightly better approach with this.

Thanks @LogMAN. After I get paying work done, I will try this out. For anyone else following along. If you are currently an OpenG developer ( @Rolf Kalbermatter?) and want to be added to the OpenG team on GitHub, send me a PM.

We can create a VIM array package for OpenG that is separate from the other array package. We could call it something else. So it could be distributed in 2017. Currently the entire OpenG sources are in a single repo. So you have to build everything in one LV version (2009). If we made each package its own repo then it could have its own LV versioning roadmap separate from the whole. See discussion here.

Well, I was hoping someone would continue the discussion, so great! We can redo the conversion. But is it really that critical to migrate the history intact? I question the need for that. If not we can start fresh. Authors - The conversion I went through had the ability to add email addresses to the author names. I just don't know what the email addresses are for the authors in Sourceforge. I've attached the author list if anyone wants to help flesh out the email addresses.Then we can rerun the conversion. Branches and tags. - I looked at the SVN repo and there's only one branch, SVN does not due branches well, so I'm not surprised nobody used that feature. There are a few tags and those are very old, circa 2007. Not sure if anybody cares about those. It seems the tagging procedure (if any) was dropped long time ago. You should be tagging with every release but that does not appear to have happened. One repo - The original SVN was a single repo, this is why i kept it the same. The conversion is a lot simpler. Breaking up a single SVN repo into multiple GIT repos and keeping the history intact seems complicated if you have commits that include files that cross library virtual boundaries. If you can think of a way to do this, that would help. Commit messages. - The commit messages are all there. It's the URLs inside the messages that are not pointing correctly, but I'm not sure what they should be point too and how to fix that during the conversion. Also, what if SourceForge changes the URL structure later? Again, is this important? Well, this is a good starting point. The alternative is to start fresh and create multiple GitHub repos, with the latest revision of the source. Then the SVN repo can be an archive if anyone wants to get at it. I welcome your help if you can create scripts to solve some of the above problems. authors.txt

I followed these instructions: https://www.atlassian.com/git/tutorials/migrating-overview I did that because my goal initially was to export to bitbucket, which I did. Then I changed my mind and decided that Github would be better for a community project like this. So then, since it was already in a Git format it was simple from within the Github website to select "import" and just point to the Bitbucket URL. Note: Those instructions work best if executed from a linux machine. I quickly spun-up an Ubuntu VM to do this.

I've exported the OpenG sources from Sourceforge SVN to Github. It's located here: https://github.com/Open-G I'm hoping this will encourage collaboration and modernization of the OpenG project. Pull requests are a thing with Git, so contributions can be encouraged and actually used instead of dying on the vine.

Not having looked at your code, do you think this should go into OpenG? How can we improve OpenG? Where is the OpenG repo?

I'm glad to see all these frameworks being bashed about. I like to read opinions from people who have tried the various frameworks and can compare based on real implementations. Not example code. Just came back from the US CLA summit (videos being posted to LabVIEW Wiki soon). Apparently there's YAF (Yet Another Framework) being used by Composed Systems and it was presented at the CLA summit: https://bitbucket.org/composedsystems/mva-framework/src/master/ It seems to be an actor-framework extension. Framework on top of framework? Jon argued that the complexity of a framework is secondary to the ability of a framework to allow certain programming concepts to be used during development. One being, separation of concerns. if you look at slide 4, Jon vehemently disagrees with that statement. In other words, you should not look at a complex framework and be afraid of it. Don't focus only on how easy it is to learn or get going with it. Question to you. What is important in choosing a framework? Here's a link to the slides: https://labviewwiki.org/w/images/2/24/Design_for_Change.pdf

The following slide was just presented at the CLA summit:

All of this spam was created a long time ago when the site was more vulnerable. The wiki has been locked down since then, and this should not happen again (but some get through). I deleted the first list of pages you mentioned. The uploaded images are tedious to delete because there no simple tool I've found to do it on a mass scale. Since they're not linked anywhere then they don't do much harm except use up server space. It seems you have time. So I will connect with you directly offline to give you some rights.