A better way to do community development of Actor Framework: GitHub

[AristosQueue (NI)]

The Actor Framework has, from the outset, been developed with the help of the community. Many of you have put up with a rather arcane way of handling source code changes as we have tested out various modifications. Well, we have a new solution that should make the whole experience much smoother. It even allows for better handling of forked editions.

National Instruments has created a GitHub repository to community source G libraries. This move is intended to be a test of a mechanism to enable customers to create customizations of NI source code and share those customizations with each other and for NI to be able to adopt some of those customizations into its core products to benefit the entire LabVIEW community.

We are beginning with just three libraries:

1. The Actor Framework, a library in vi.lib since LV 2012
2. The NI-GOOP Development Suite, a free toolkit add-on for improving LabVIEW class development
3. The AQ Character Lineator, a library not yet in vi.lib to support serialization/deserialization of LabVIEW classes

If this experience working with the community proves fruitful, NI may expand the number of our APIs that are part of this sharing.

For more information, including instructions on how to access the GitHub repository, please visit this community:

https://decibel.ni.com/content/groups/community-source-of-ni-code

[JonJay]

I'm very excited to hear this. Now I feel like I can continue to contribute to the AQ Character Lineator without worrying about mismatching the latest code base. I'll look into getting this tested on my machine to see how easily it is to deal with.

[JonasCJ]

Sorry if this is off-topic, but I am wondering about the git-workflow that will have to accompany the use of git to manage the AF project.

So the Actor Framework distribution (https://decibel.ni.com/content/docs/DOC-23397) comprise of classes (.lvclass), libraries (.lvlib), controls (.ctl) and VIs (.vi).

Out of these lvmerge and lvdiff can only handle VIs (.vi). How do someone merge in their feature when there is no merge or diff utility for classes, libraries and controls?

Changes to classes and controls are probably more rare than changes to VIs and libraries, but conflicting changes to one of these four file types must happen from time to time.

Does one open up the master branch and ones feature branch on two seperate computers and do a completely manual merge (right click on classes to see their properties and sync those differences up)? Or does one do text-diff/text-merge on the class files and library files (they are just XML)?

If this is not the place to discuss this please advice on where I might ask this instead

Edit:

Judging from https://decibel.ni.com/content/docs/DOC-37195 at least some NI employee will have this headache since the guidelines (quoted below) says that when a feature is ready a pull-request should be issued and then an NI employee will evaluate the changes.

So NI themselves must know a nice way to merge these non-VI-types or they are doing the in some suboptimal way like the rest of us...

8. Please do NOT make changes to the “master” branch of any project on “ni-dev”. Instead, create your own branch (not a fork, just a branch) to make changes. The “master” branch will be updated only when NI updates the core product distribution. Any changes pushed into the master branch by non-NI employees will be reverted.

9. If you choose to ALSO make a fork (and there are good reasons for doing so), updating your fork does not suffice to have shared your changes with the community. You must push your changes back into a branch within the “ni-dev” repositories before distributing your changes to other users.

10. When you have your branch in a form that you believe is ready for inclusion in the main NI product, submit a New Pull Request to the “ni” organization. These pull requests will be evaluated by NI employees for inclusion or exclusion in the main NI distributions. Pull requests to the “ni” repository will be approved or rejected at NI’s discretion. Rejected pull requests will generally remain available on the “ni-dev” repository.

/ JonasCJ