You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
CSTF have suggested that designated proponents could be responsible for any codec-specific changesr required to verify content is conformant to WAVE/CMAF.
An approach could be that proponents or their agents could fork the github source code at https://github.com/Dash-Industry-Forum/Conformance-and-reference-source, edit a local copy of this, and check the changes back into their fork. They would then submit a PULL request for this code to be merged onto the main trunk. Whoever has been appointed as the maintainer of the code base would then determine whether to proceed with the final merge, would build the resulting code, and would distribute the executables to the onlline tool and to the https://github.com/Dash-Industry-Forum/Conformance-Software repository.
TBD: Is some form of coding guidelines necessary? For e.g. code related to a specific codec should be kept in seperate source files with only the minumum changes necessary made to the "core" code.
TBD: How will regression testing of existing code be handled, i.e. how to ensure that a merge for a particular codec has not broken other functionality?
The text was updated successfully, but these errors were encountered:
FYI: John Simmons has has circulated an email to the CSTF highlighting the respective proposal in the Test Approach document. So we are awaiting comments and feedback.
CSTF have suggested that designated proponents could be responsible for any codec-specific changesr required to verify content is conformant to WAVE/CMAF.
An approach could be that proponents or their agents could fork the github source code at https://github.com/Dash-Industry-Forum/Conformance-and-reference-source, edit a local copy of this, and check the changes back into their fork. They would then submit a PULL request for this code to be merged onto the main trunk. Whoever has been appointed as the maintainer of the code base would then determine whether to proceed with the final merge, would build the resulting code, and would distribute the executables to the onlline tool and to the https://github.com/Dash-Industry-Forum/Conformance-Software repository.
TBD: Is some form of coding guidelines necessary? For e.g. code related to a specific codec should be kept in seperate source files with only the minumum changes necessary made to the "core" code.
TBD: How will regression testing of existing code be handled, i.e. how to ensure that a merge for a particular codec has not broken other functionality?
The text was updated successfully, but these errors were encountered: