Transfer project hosting to Github/Bitbuck

[odoylerules]

I was curious if there has ever been any consideration of transferring the OpenG repository from SourceForge to either GitHub or Bitbucket?  

 

Both services support direct SVN repository import.  It seems to me that it would be a much better way for others to contribute code to the project with pull requests and track issues such as the LinuxRt zip files changes. Sourceforge just doesn't offer any of these collaborative tools that have become a standard in the last few years.  In addition, both provide direct binary file downloads, with Github's release function being extremely useful.  

 

Considering OpenG might be the most used open source Labview tool, i personally think it would be nice to follow the best practices of other languages open source project code sharing and collaboration.  

 

PS: SourceForge has had some shady practices lately with bundling  crapware with installers.  Gimp for example.  Not really an issue for .vip packages but still shady.   

 

 

[jgcode]

  On 2/24/2016 at 2:59 AM, odoylerules said:

would be a much better way for others to contribute code to the project   

 

I am unsure if a new workflow would increase contribution but, what do others think?

[Rolf Kalbermatter]

  On 2/26/2016 at 8:31 AM, jgcode said:

I am unsure if a new workflow would increase contribution but, what do others think?

 

I can only speak for myself, but I do find the GIT workflow not really very easy. I'm sure there are some tools nowadays that make it quite a bit easier to use, but the impressions I got when comparing SVN to GIT several years ago, was that SVN was simply there to use while with GIT you had to learn a whole bunch of magic incantations and remember arcane commands and specific sequences or you ended up with a bigger mess in your project than when using the simple old ZIP-it-all-up source code control system. 

 

That all said, if there are people who really want to use GIT and are eager to revive the OpenG initiative if it is moved to a GIT based site, they shouldn't be blocked from it. I don't have much to say about that as my current submission rate to OpenG is just very slightly above 0 and hardly can drop much even if I should decide to not like the new workflow.

[ShaunR]

  On 3/1/2016 at 7:58 AM, rolfk said:

I can only speak for myself, but I do find the GIT workflow not really very easy. I'm sure there are some tools nowadays that make it quite a bit easier to use, but the impressions I got when comparing SVN to GIT several years ago, was that SVN was simply there to use while with GIT you had to learn a whole bunch of magic incantations and remember arcane commands and specific sequences or you ended up with a bigger mess in your project than when using the simple old ZIP-it-all-up source code control system. 

 

That all said, if there are people who really want to use GIT and are eager to revive the OpenG initiative if it is moved to a GIT based site, they shouldn't be blocked from it. I don't have much to say about that as my current submission rate to OpenG is just very slightly above 0 and hardly can drop much even if I should decide to not like the new workflow.

Glad I'm not the only one. Even if you account for not being able to diff LabVIEW code - which is a huge benefit of SCC - the creation of hundreds of clones of the source code trunk as a normalised workflow is an abomination.

 

I think the idea was originally to be able to pick and choose code created by the herd of cats to improve the trunk but what actually happens is you end up with 1,000 slightly different variation of the same thing none of which are exactly what you want. So.....you create another clone .

[Rolf Kalbermatter]

Well I'm sure the GIT system was exactly developed for what you see as original idea. And it works amazingly well for certain projects with a central maintenance like the Linux kernel or the Wine project. However lacking such centralized maintenance it tends to get the cloning mess you allude to. Because most developers are just wanting to get this new awesome feature into the software and not worry about integrating it in the main branch.

 

I still follow the Wine project a bit and it is the single most problem there, some contributor has a great new idea and drops a patch, but then when faced with the trouble of integrating it into the whole and complying with common styles, formatting and following proper error handling and making sure the modified code passes all unit test, the majority just starts to complain about the stringent rules and eventually abandons it.

 

Even in text programming, merging a software branch back into the trunk is often a very tedious, and work intense process, that even advanced code merging algorithms never will be able to fully automate, since it is not always enough to just look at the factual differences in code, but the whole context often has an influence too.

 

And with even basic automatic LabVIEW code merging being still a pipe dream, this makes the distributed development model of GIT more of a liability to LabVIEW source code control rather than an advantage.

[ShaunR]

  On 3/1/2016 at 10:47 AM, rolfk said:

I still follow the Wine project a bit and it is the single most problem there, some contributor has a great new idea and drops a patch, but then when faced with the trouble of integrating it into the whole and complying with common styles, formatting and following proper error handling and making sure the modified code passes all unit test, the majority just starts to complain about the stringent rules and eventually abandons it.

 

I think it is a Linux cultural thing compounded by young basement hackers, personally.

 

I saw a discussion somewhere where an application developer likened most programs written by Linux people today to a game called "Mount Your Friends". Seeing the go-to "architecture" (and I use the term loosely) of writing applications is to pipe and string together, program after program and hack upon hack , with the mantra "it works so it must be good" - I'm inclined to agree with them

 

The Linux world has the cleverest, most intelligent and awe inspiring coders and programmers that there is. I'm humbled by some of their abilities' to put advanced mathematics and theories into code........ but they couldn't write a decent or user friendly application if their life depended on it .

[odoylerules]

So i'm not trying to start an SVN vs GIT war here.  I personally started with SVN and switched to GIT and i don't consider myself a master of either.  Some of the issues you are raising are inherent to any SCC when using labview, specifically merging, testing and code compliance.  However, some of the points you are raising about GIT i don't think are accurate and are probably outdated relative to its current version.  

 

The strength of GIT is its distributed model and its ability to clone and fork without impacting other repositories.  I personally find its to be its biggest strength.  It makes collaboration a lot easier.  The ability to easily branch, fix an item and then bring it back into your main development branch is essential and just not something you can do easily with SVN.  They are very different SCC methods and i think there is some confusion on how git works in this thread.

 

However, disregarding the SVN vs GIT debate, my main thought was more on the distribution side as SourceForge is just not a good host for things like this.  I suggested Github.com, not expecting the maintainers to switched to GIT, but specifically b/c you can import SVN repositories and use SVN commands/clients while hosting the code on Github.com.  In addition, github.com provides binary distribution, issue tracking and management from a single unified place.  While i read lavag.org all the time, using a forum to track code issues is a very outdated method.  

 

Now i'm not exactly familiar with the past OpenG development process and maintenance procedures, it obviously a mature library and so changes are rare.  But one thing i think the Labview community should really start embracing is the open source model and project distribution structure that you find on github.com.  The ability to collaborate and share code in a centralized location is what makes github so powerful and popular.  There is a reason it has become so big in the last few years, its b/c its model works.

 

So basically my thought was since OpenG is so popular it would be a good test source for the Labview community on sharing open source code.  If it isn't a good candidate for this, then no big deal.  

Edited March 1, 2016 by odoylerules

[ShaunR]

  On 3/1/2016 at 4:20 PM, odoylerules said:

The strength of GIT is its distributed model and its ability to clone and fork without impacting other repositories.  I personally find its to be its biggest strength.  It makes collaboration a lot easier.  The ability to easily branch, fix an item and then bring it back into your main development branch is essential and just not something you can do easily with SVN.  They are very different SCC methods and i think there is some confusion on how git works in this thread.

 

That's just regurgitating the spiel.

 

The power of Git isn't in forking or cloning - you can do that by copying a zip file. It is in having a local repository that you can make incremental commits and checkouts that can also be synchronised with the main trunk - offline AND online commits or "staging" as it is called. Other SCC all have to be on-line to make commits.

 

The point  I (and I think Rolf) are making is that all SCC including Git are not fit for purpose when it comes to LabVIEW so why change from one inadequate source control to another inadequate source control? It's not as if we have never used Git. It's just that is it as crap as all the others for LabVIEW. I, certainly, end up just using them purely for backup and restore due to LabVIEW peculiarities and Git is a very complicated backup and restore.

 

Whats really needed is for NI to get their finger out and give us a proper LabVIEW SCC system instead of faffing around with IDE cosmetics

Edited March 1, 2016 by ShaunR

[odoylerules]

Well obviously you would prefer to continue to SCC war so i guess that's an end to this thread.  As i mentioned the purpose of this request was to address the ability to easily share and collaborate on code, given the current tools and options of labview.  

 

The Github sharing culture is a standard for all sorts of other programming languages and in my opinion one that Labview should move towards and mirror.  I could go on and on about issues with Labview.  Honestly its a pain to use compared to other languages.  While i appreciate your comments, complaining about labview's source control issues has nothing to do with this thread.  

 

If this type of source sharing doesn't work for you that's fine, continue zipping and copying files, nothing is stopping you.  In fact, you can upload zip files to bitbucket/github all day long.  However, I'm still not understanding your argument.  Merging changes is hard so we should only use zip files and forum post and we shouldn't make it easier to track changes and collaborate outside of the lavag community? 

 

Obviously the reluctance to change is strong in the community and that's unfortunate given that this website holds knowledge from all the best labview programmers.  However, if you really want the popularity of labview to grow, a strong open source involved culture is key.  Learning to use Github or a similar website to foster that culture is critical.

[Rolf Kalbermatter]

  On 3/1/2016 at 6:39 PM, odoylerules said:

Well obviously you would prefer to continue to SCC war so i guess that's an end to this thread.  As i mentioned the purpose of this request was to address the ability to easily share and collaborate on code, given the current tools and options of labview.  

 

The Github sharing culture is a standard for all sorts of other programming languages and in my opinion one that Labview should move towards and mirror.  I could go on and on about issues with Labview.  Honestly its a pain to use compared to other languages.  While i appreciate your comments, complaining about labview's source control issues has nothing to do with this thread.  

 

If this type of source sharing doesn't work for you that's fine, continue zipping and copying files, nothing is stopping you.  In fact, you can upload zip files to bitbucket/github all day long.  However, I'm still not understanding your argument.  Merging changes is hard so we should only use zip files and forum post and we shouldn't make it easier to track changes and collaborate outside of the lavag community? 

 

Obviously the reluctance to change is strong in the community and that's unfortunate given that this website holds knowledge from all the best labview programmers.  However, if you really want the popularity of labview to grow, a strong open source involved culture is key.  Learning to use Github or a similar website to foster that culture is critical.

 

Shaun wasn't talking about zipping up code for source code control purposes. Just that the additional benefits of GIT compared to SVN, which is currently used for OpenG, basically diminish to nothing, since merging is a highly manual process. Seeing so many GIT clones abandoned quickly on "normal" languages, where automatic merging is at least a possibility albeit even there never without thorough manual review of any merge, the collaborative advantages of GIT simply get lost when it comes to LabVIEW code. SVN works for that just as good if not better thanks to very intuitive and easy to use clients like TortoiseSVN. Yes there is a TortoiseGIT client too, and I tried it but it does show regularly the unix origins even when using it as Windows shell extension. Not the type of seamless integration that makes these things easy to use for people who want to program rather than read manuals.

 

Sourceforge having issues is undeniable and that might be indeed a reason to consider to change the provider for the source code control repository for OpenG, but GIT has definitely not any serious advantage in comparison to using SVN when it comes to LabVIEW code. Also I really doubt there will be suddenly any inrush of new people reviving the OpenG initiative because of such a change. LabVIEW is a nish product, used mostly in industry applications, and most users have paid jobs that makes collaborating on OpenG like initiatives kind of hard. And the others have moved on to Python and the like since.

 

The popularity of LabVIEW won't change because of moving OpenG to things like Github. The popularity of LabVIEW is at the point of what it is, because of decisions made by NI about how to market this language. They are or have been fairly agressive about getting it into educational institutions to get future engineers acquainted with it before they move into the industry, but they were and are very reluctant to loosen the control on LabVIEW in any way. As such it has been and still is a proprietary and a single source application development program, rather than a general purpose programming language, despite the fact that it is technically a fully functional programming language.

 

From a commercial point of view history has shown that their decision was in fact a very successful and profitable one. For the academical purpose of graphical programming languages it was less favorable, but you can't fault a stock market traded company for choosing the profitable approach.

[ShaunR]

  On 3/1/2016 at 6:39 PM, odoylerules said:

Well obviously you would prefer to continue to SCC war so i guess that's an end to this thread.  As i mentioned the purpose of this request was to address the ability to easily share and collaborate on code, given the current tools and options of labview.  

 

The Github sharing culture is a standard for all sorts of other programming languages and in my opinion one that Labview should move towards and mirror.  I could go on and on about issues with Labview.  Honestly its a pain to use compared to other languages.  While i appreciate your comments, complaining about labview's source control issues has nothing to do with this thread.  

 

If this type of source sharing doesn't work for you that's fine, continue zipping and copying files, nothing is stopping you.  In fact, you can upload zip files to bitbucket/github all day long.  However, I'm still not understanding your argument.  Merging changes is hard so we should only use zip files and forum post and we shouldn't make it easier to track changes and collaborate outside of the lavag community? 

 

Obviously the reluctance to change is strong in the community and that's unfortunate given that this website holds knowledge from all the best labview programmers.  However, if you really want the popularity of labview to grow, a strong open source involved culture is key.  Learning to use Github or a similar website to foster that culture is critical.

 

I suggest you count to 10 then re-read what I wrote.

[Rolf Kalbermatter]

  On 3/1/2016 at 5:56 PM, ShaunR said:

Whats really needed is for NI to get their finger out and give us a proper LabVIEW SCC system instead of faffing around with IDE cosmetics

 

I'm not sure that is desirable! Bigger companies have failed very badly to provide a working source code control system (anyone ever tried to use Visual Source Safe?), so I don't have high hopes that an SCC offering from NI would be better than what we can get now with openly availabe Open Source tools.

 

That smoother and more effective merge tools for LabVIEW would be a good thing is unquestionable. But the task of comparing vectors and directed graphs with each other is a magnitude or two more complex than simple text code comparison and to automate that would seem a really complicated task that whole generations of computer science programmers could spend years on. Given the closed source nature of LabVIEW that is however not going to happen.

[ShaunR]

  On 3/1/2016 at 7:35 PM, rolfk said:

I'm not sure that is desirable! Bigger companies have failed very badly to provide a working source code control system (anyone ever tried to use Visual Source Safe?), so I don't have high hopes that an SCC offering from NI would be better than what we can get now with openly availabe Open Source tools.

 

That smoother and more effective merge tools for LabVIEW would be a good thing is unquestionable. But the task of comparing vectors and directed graphs with each other is a magnitude or two more complex than simple text code comparison and to automate that would seem a really complicated task that whole generations of computer science programmers could spend years on. Given the closed source nature of LabVIEW that is however not going to happen.

Well. A bit off topic but deserves a response.

Two points here.

.

1. They have already figured out how to identify and merge differences. In fact they figured it out a long time ago, then stopped. That's 80% of the problem already solved, IMO.
2. I've said before and I'll say it again. I don't care that the features I want are hard. It's closed source, paid-for software so it's up to NI to figure out how to make it happen; not for you or I to be technical apologists for them. Anything is possible with enough resources, time and the will to do it. The only thing lacking is the last one.

 

As far as I can tell,. NI stopped doing hard or interesting stuff in LabVIEW around 2009 (maybe even 8.x) and have been serving us IDE placebos ever since - just look at whats been implemented from the idea exchange!  

[Rolf Kalbermatter]

The merging capability isn't exactly working well, definitely not something to use in automated merging during GIT pull requests.

 

As to that the development of LabVIEW seems to have stagnated I can't deny that. There have been two quite large architectural changes in the last 7 to 8 years. One is the support for 64 bit targets which got substantiated in version 2009 and finished with the 64 bit versions for Linux and Mac in version 2014. Especially the Mac version must have been a major work as more or less everything had to be changed from the Carbon framework to the Cocoa framework. That is a major change in the code base, most likely with the addition of Objective C code specifically for this move (many Cocoa APIs are not really accessible from C or C++ code).

 

The other big change was the introduction of the LLVM compiler backend around 2011. As it is something that works in the background, not much should have been felt from it for the end user. Technologically however it is a major change to the code base. The fact that it has been so largely invisible to the users is in fact a big achievement, as it has huge chances to break lots of things in many places.

 

So it's not like there hasn't been much development going on in LabVIEW, but a lot of the last big changes are almost invisible to the end user.

 

There has been for several years a lot of work going on to modernize LabVIEW. Quite some of it was in the underlying infrastructure such as multiplatform support (not just multi-CPU and -OS as originally developed), LLVM compiler backend and many more things. The UI side of LabVIEW is however burdened with lots of legacy liabilities that can't easily be changed without breaking lots of things and user expectations. Keep an eye out for new developments there. It won't be as invisible as the other changes mentioned and not everybody is going to like them . Breaking old habits is one of the most difficult things to do.

[ShaunR]

  On 3/2/2016 at 3:15 PM, rolfk said:

The merging capability isn't exactly working well, definitely not something to use in automated merging during GIT pull requests.

 

As to that the development of LabVIEW seems to have stagnated I can't deny that. There have been two quite large architectural changes in the last 7 to 8 years. One is the support for 64 bit targets which got substantiated in version 2009 and finished with the 64 bit versions for Linux and Mac in version 2014. Especially the Mac version must have been a major work as more or less everything had to be changed from the Carbon framework to the Cocoa framework. That is a major change in the code base, most likely with the addition of Objective C code specifically for this move (many Cocoa APIs are not really accessible from C or C++ code).

<snip>

The DFIR was introduced in 2009 and LLVM in 2010, I think.

 

Anyway. Enough off topic shenanigans . Back to the discussion "my SCC could take your SCC in a fight"..

 

I think the answer as to whether things should move to Git is probably not down to features, but preferences. If 90% of people prefer Git because all their other projects are there, then why not?. If no-one cares apart from 1 or 2 zealots then there is little point. Maybe a straw poll?

 

There is one input that has not been considered, and it is the amount of effort required by the OpenG team to actually move it and if it would have a negative impact on the existing contributors who may be reluctant to learn a new platform.

Edited March 2, 2016 by ShaunR

[Rolf Kalbermatter]

Actually there is one point which comes to mind. VIPM including the latest version does pull all the OpenG libraries from Sourceforge. Moving that to another server would render all existing VIPM installations non functional for downloading OpenG libraries. I'm sure there is a way to change a configuration file or something in VIPM that could let it use another server and the Pro version supports arbitrary server locations but that may all have its own trouble and complications.

[JKSH]

  On 3/2/2016 at 4:18 PM, ShaunR said:

Anyway. Enough off topic shenanigans . Back to the discussion "my SCC could take your SCC in a fight"..

 

There is one input that has not been considered, and it is the amount of effort required by the OpenG team to actually move it and if it would have a negative impact on the existing contributors who may be reluctant to learn a new platform.

 

Reading through this thread, it appears to me that neither odoylerules nor yourself wanted to start a "My SCC vs You SCC" debate, but you've both ended up talking about specific SCC features in detail.  

 

Here's what odoylerules wrote: "...disregarding the SVN vs GIT debate, my main thought was more on the distribution side as SourceForge is just not a good host for things like this.  I suggested Github.com, not expecting the maintainers to switched to GIT, but specifically b/c you can import SVN repositories and use SVN commands/clients while hosting the code on Github.com.  In addition, github.com provides binary distribution, issue tracking and management from a single unified place.  While i read lavag.org all the time, using a forum to track code issues is a very outdated method."

 

Regarding these points, SourceForge provides "binary distribution, issue tracking and management from a single unified place" too, and I see that the SourceForge issue tracker has many entries (albeit not for the past 3 years). It's just that our community prefers a different distribution platform (VIPM), and I'm guessing that many casual users aren't aware of the SourceForge issue tracker. I don't know if switching to a different host (no matter which SCC backend is used) will change this.

 

Anyway, if the main concern was distribution, I think VIPM is superior to any integrated binary download mechanism provided by online repository hosts.

 

I'm not convinced that switching SCC backends will change OpenG's rate of contribution either.

 

 

 

  On 3/2/2016 at 4:18 PM, ShaunR said:

There is one input that has not been considered, and it is the amount of effort required by the OpenG team to actually move it and if it would have a negative impact on the existing contributors who may be reluctant to learn a new platform.

 

Is there a list of of existing contributors? So far I've only been able to find the list of authors for individual VIs embedded in the front panels.

Edited March 3, 2016 by JKSH

[Rolf Kalbermatter]

  On 3/3/2016 at 12:14 AM, JKSH said:

Regarding these points, SourceForge provides "binary distribution, issue tracking and management from a single unified place" too, and I see that the SourceForge issue tracker has many entries (albeit not for the past 3 years). It's just that our community prefers a different distribution platform (VIPM), and I'm guessing that many casual users aren't aware of the SourceForge issue tracker. I don't know if switching to a different host (no matter which SCC backend is used) will change this.

 

Anyway, if the main concern was distribution, I think VIPM is superior to any integrated binary download mechanism provided by online repository hosts.

 

AFAIK VIPM pulls the actual packages from the sourceforge servers (and the NI Tools Network server). So besides moving all the content to another site you would either have to leave the build packages on sourceforge or find a way to easily let VIPM reference this new server instead. Am not even sure how binary packages on github work and if they are easily referenced by external package managers like VIPM.

 

  Quote

Is there a list of of existing contributors? So far I've only been able to find the list of authors for individual VIs embedded in the front panels.

 

I think there doesn't exist a authoritative list like that. It would be possible to create a fairly accurate list with some effort albeit there is no warranty that it would be complete, but so far people only have asked for this. Nobody ever went to the effort to actually start to create something like this.

 

Even if you had that list several people on it have moved on and are not actively involved in LabVIEW work anymore and may not even follow this microuniverse anymore.

[JKSH]

  On 3/2/2016 at 4:18 PM, ShaunR said:

There is one input that has not been considered, and it is the amount of effort required by the OpenG team to actually move it and if it would have a negative impact on the existing contributors who may be reluctant to learn a new platform.

 

Github can interface with SVN clients, so users could in theory continue to use their preferred SVN tools: https://help.github.com/articles/support-for-subversion-clients/ (I'm guessing that the commit messages will be marked with the fact that the SVN interface was used)

 

 

  On 3/3/2016 at 8:04 AM, rolfk said:

AFAIK VIPM pulls the actual packages from the sourceforge servers (and the NI Tools Network server). So besides moving all the content to another site you would either have to leave the build packages on sourceforge or find a way to easily let VIPM reference this new server instead. Am not even sure how binary packages on github work and if they are easily referenced by external package managers like VIPM.

 

Hmm... leaving the last version behind on the old host as an archive is quite common, I believe. OpenG releases are now quite rare, so users probably wouldn't even notice (for years?) if we moved  Another common practice of large projects is to use one host for the "master repo", while mirroring the project on other hosts in read-only mode.

 

 

  On 3/3/2016 at 8:04 AM, rolfk said:

...find a way to easily let VIPM reference this new server instead. Am not even sure how binary packages on github work and if they are easily referenced by external package managers like VIPM.

 

Github has a feature called "Releases". Here's an example, which contains a direct download link to a .vip which I presume VIPM can grab: https://github.com/JKISoftware/JKI-State-Machine/releases

 

In a nutshell, when you're ready to release a new version, attach a Tag^ to the relevant commit and ask Github to create a Release from that Tag. Github automatically creates a snapshot of the source code in a .zip and a .tar.gz file for this Release. You can then upload your built binary packages into that same Release.

 

^With SVN, developers conventionally copy a snapshot of the source code into the "tags" folder to mark a new version, although SVN itself has no concept of tags. In contrast, Git tags are text labels that can be applied to any commit; developers conventionally apply a tag to mark a new version.

 

 

  On 3/3/2016 at 8:04 AM, rolfk said:

I think there doesn't exist a authoritative list like that. It would be possible to create a fairly accurate list with some effort albeit there is no warranty that it would be complete, but so far people only have asked for this. Nobody ever went to the effort to actually start to create something like this.

 

Even if you had that list several people on it have moved on and are not actively involved in LabVIEW work anymore and may not even follow this microuniverse anymore.

 

I guess I just got curious after reading Shaun's comment; I don't need/want it enough to spend time making such a tool If I were to do it though, it would probably involve VI scripting, iterating across all OpenG VIs, grabbing strings from each front panel,  searching for the string "Copyright ©", and using regex to extract the name/email that comes after that string.

[ShaunR]

  On 3/3/2016 at 12:14 AM, JKSH said:

Reading through this thread, it appears to me that neither odoylerules nor yourself wanted to start a "My SCC vs You SCC" debate, but you've both ended up talking about specific SCC features in detail.  

 

Nope. I just said all SCCs are crap for LabVIEW including Git. Rolf was comparing Git and SVN features. That comment was a friendly dig at odoylerules who loves Git and thinks my SCC system is copying zip files

 

  On 3/3/2016 at 12:14 AM, JKSH said:

Is there a list of of existing contributors? So far I've only been able to find the list of authors for individual VIs embedded in the front panels.

This is the same problem that came up with people wanting to know how to attribute the OpenG software for licencing. Various people suggested similar things to you but I'm not sure if an authoritative answer was ever proffered.