Contribution Repositories

[ajcraig]

Hey All,
Yesterday we had a great discussion revolving around contributions, types, and where to store contributions to assist us in our goal of completing the Revision 1 of the Margo Specification.
I’m proposing the following definitions and clarifications.

Create Repositories for Prototype/Testing/Tooling to assist working groups achieve the goals of the specification section.

• Engineers need to ensure that the contributions do not violate any employer IP rights.
• These are planned to be public repositories.
• Repositories will be created per focus group along with an additional one for System Architecture Prototypes

Blueprint repository to create templates / scenarios that are enabled by the Margo envisioned system design.

• This repository is envisioned to house blueprints that target various users of the Margo specification.
• Examples are shown below:
  • Target: End-User
    • Crumble Co that has the full ecosystem being margo compliant
  • Target: Product Vendors
    • Defining an helm chart based app via Margo specification
    • Deploy app to Kubernetes Cluster
    • Deploy app to Docker Compose Edge
    • Serve telemetry to app provider
    • Take an Intel NUC and make it margo compliant
    • Schneider Standalone device being onboarded to a Rockwell Device Orchestration software
• Contributions within this repository should have a disclaimer stating which components of the templates/blueprints are margo compliant and what are inherited by the technology of choice.
  • See example here: https://github.com/margo/blueprints/blob/master/crumbleco/single-smart-oven/symphony/README.md
• Our first contribution to this repository was done via Haishi and is ready for review/testing.
• This is planned to be a public repository.

Official Reference Implementation repository

• This repository will be utilized for official Reference Implementation components that are compliant and verified via the Test and Compliance suite.
• Components within this repository allow Product Vendors with “quick start” components to reference or utilize within the product offerings.
  *Example: Margo creates a reference implementation for the Workload Orchestration Agent.

Last note: Philip would like to enable the “Packages” feature within our Margo Github Organization to enable developers to house their packages within the same ecosystem as their prototypes/tooling.

From my understanding all three of these repositories will be covered under the MIT License.

Let me know your thoughts.
Armand

[phil-abb]

Did we want to make the Prototype/Testing/Tooling repositories public? Or make them only visible to members?

[ajcraig]

Did we want to make the Prototype/Testing/Tooling repositories public? Or make them only visible to members?

The goal is to be as transparent as possible in regards to our conclusions and tools that we utilized to get to them. With that in mind, we need to have a disclaimer stating nothing in this particular repo is "Supported" unless it is inter working group collaboration.

[phil-abb]

The goal is to be as transparent as possible in regards to our conclusions and tools that we utilized to get to them. With that in mind, we need to have a disclaimer stating nothing in this particular repo is "Supported" unless it is inter working group collaboration.

I'm ok with making these public if that is what we want to do. However, if by doing this it means we have to enforce a heavy policy on top of these repos then I feel it will be a hindrance.

For example, I've been working on a prototype for a few different reasons. I have no expectations for anyone else doing anything with the prototype. I don't want to be blocked from making changes to the prototype because of requirements like needing other people to review PRs, needing unit tests, needing production-level documentation, etc. The prototype is for learning and trying things out as the specification evolves and is not something intended for customers/the public. It's possible in the future the prototype might evolve enough to where we might want to move parts of it to the Blueprint or Reference implementation repo but this is a different path and may not ever happen.

The same holds with the scripts Amir and I have been working with for the Observability focus group. We want to be able to iterate on these scripts quickly and shouldn't have to keep them in a state where customers can use them. If over time we want to make them available for customers/the public then they would be made available through the Blueprint or Reference implementation repos only.

[jorydotcom]

@ajcraig does the new per -fg repos close this issue?

[ajcraig]

@ajcraig does the new per -fg repos close this issue?

I will make a point to discuss this on Thursday again before we close it. Due to the other repos "Blue-Print" and "Reference implementation".

But that part is done, correct.