Whoa, whoa, whoa…. You’re conflating two things. Codebase/product/branching and naming. The name has absolutely nothing to do with the questions you brought up below. Nothing. There is absolutely no relationship whatsoever.
But to answer your questions, I think there is some serious confusion. Juniper is moving to a model where it is a primary consumer of the XYZ (to maintain your convention) project. The Contrail product will incorporate XYZ without modification. That means there is no internal fork of the XYZ codebase. All of our work will be done upstream in the XYZ codebase except for anything that is part of the proprietary code of the Contrail product. More specifically to your five questions: 1. There will be NO internal Contrail branch; all features added in XYZ would wind up in the Contrail product codebase, with a caveat: a. The commercial Contrail product may not officially support features upstreamed in XYZ and incorporated in the Contrail codebase until we have tested and validated them to our own satisfaction; our product testing and supported features for Contrail will be necessarily different from XYZ even if the code exists in Contrail 2. There is NO separate branch; all code will be contributed to XYZ for all core features and open source capabilities, with a caveat: a. We are moving to an “open core” model where the Contrail product is 100% open source XYZ + proprietary UI and analytics codebase that is NOT open source, so … b. ALL code that we crate that is not the UI or analytics is contributed to XYZ first and there is NO FORK OF THAT CODE BASE 3. The TSC drives the decisions on branching of the XYZ codebase 4. You are confused; Contrail is completely interoperable with XYZ because it *IS* XYZ with the exception of the UI and the analytics engine; similarly it’s our intention that XYZ deployments can be upgraded to Contrail and that Contrail deployments could be downgraded to XYZ; this is not achievable if we have a fork or use a different codebase 5. No, we’re going to work closely with the community to make XYZ awesome because we are entirely dependent on it I’m not sure how this got confused. Even today, with the 4.x line of code, Juniper is predominantly operating in the open and most of the codebase is modified in public. There have been some wonky pieces of the build and release system that confused this, but that’s all being re-jiggered over the next month or so. Juniper does not maintain a separate internal codebase for Contrail separate from XYZ/OpenContrail and has no intention to do so; *other* than the new GUI and analytics engine which are proprietary components to our product. --Randy Vice President, Technology & Strategy, Cloud Software Juniper Networks +1 (415) 787-2253 [Google Voice] ASSISTANT: Stephanie Concepcion, sconcepc...@juniper.net<mailto:sconcepc...@juniper.net> TWITTER: @randybias LINKEDIN: linkedin.com/in/randybias From: <rras...@gmail.com> on behalf of Robert Raszuk <rob...@raszuk.net> Date: Tuesday, December 5, 2017 at 2:39 PM To: Randy Bias <rb...@juniper.net> Cc: "dev@lists.opencontrail.org" <dev@lists.opencontrail.org> Subject: Re: [opencontrail-dev] The Controversy around Renaming OpenContrail Hi Randy, > To recap, we’re in the process of creating a vehicle that would allow > community-led governance > of OpenContrail. That process will result in some kind of entity, besides > Juniper, that owns the > governance, codebase, and related trademarks. Let's assume the new name for community OpenContrail is XYZ. Can you answer few simple questions yet very critical to the future of both community XYZ & Juniper's Contrail: * If community adds new features to XYZ is Juniper/Contrail engineering going to sync it into the internal Contrail branch such that *all* such features are part of it ? * If Juniper engineering/PMs add a new feature or bug fix to Juniper's Contrail will it get also commited to community XYZ branch ? * Who and how will decided what goes into what branch ? * If there is no 100% of feature and bug fix party how are you going to make sure both XYZ & Contrail are even interoperable ? * Is Juniper going to internally keep texting community XYZ version ? Many thx, Robert.
_______________________________________________ Dev mailing list Dev@lists.opencontrail.org http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
