VCA uses an open-source development model
VCA is being tested on more hardware and software configurations, under a wide variety of settings and with a wide variety of content. Users can pull source code updates from our dev branch and test new features as soon as they are available. In this way, bugs can be identified more quickly, leading to more robust code.
VCA code changes are public. Patches (proposed code improvements) are sent through the VCA development mailing list, for review by all VCA developers. Public code review leads to more robust code. Issues are identified and resolved before the proposed patch is committed.
Contribute to VCA
The VCA development team invites contributions from talented developers. Today, more than 70% of the bits crossing the Internet are video. But before it gets encoded or streamed, mostly, all of that video needs to first be analyzed/pre-processed. VCA is one of the software libraries which can be used for real-time applications like live per-title encoding. Your contributions will be highly visible and highly valued. Video software developers are in high demand, and VCA is the perfect project to show the world that you know what you’re doing.
How to join the VCA project as an open-source developer?
First, get to know VCA. VCA Documentation is distributed with the source and posted on https://cd-athena.github.io/VCA/. Next, get to know the VCA source code. The source code can be found here. We suggest using Git to clone or pull from our repository and manage your local copy of the VCA source. To figure out what parts of VCA you can help with, take a look at our Issues list. Lastly, you should read how to contribute patches to VCA. We require a signed contributor agreement before we can accept patches.
Release Management
VCA follows the standard branching methodology of Git. The repository will have two named branches, stable and dev. All new development is performed in the dev branch, while the stable branch is for bug fixes only until we get to a release cycle. Each time a bug fix commit is made to the stable branch, that bug fix is merged into the dev branch. When we decide that we want to release the contents of the dev branch, we begin a short period of heavy testing and then merge the dev branch onto stable. Once the tag is made, the dev branch is opened again for new development. Since VCA is a young project, there is no pre-defined release tag cadence. It will happen as often as is convenient and necessary.
