Robert, Relationship of the product and project is going to be closer than before. Project and product will share master and initially even release branch. Our ultimate goal is to have community build be the foundation for the commercial release but it take time to get there.
So the code for the feature will be in commercial product. This is not a commitment from Juniper to officially support a specific feature in Juniper commercial release. The QA resources are limited. So just like commercial openstack releases cherry pick community features for commercial support, so will commercial contrail release cherry pick which community features are supported by juniper. How commercial support will work when community features are activated in production is TBD. I will answer the rest inline. Thanks Greg From: Dev <dev-boun...@lists.opencontrail.org> on behalf of Robert Raszuk <rob...@raszuk.net> Date: Tuesday, December 5, 2017 at 2:40 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 ? no internal branch, but maybe a release branch if the community decides to go off cycle. All feature in master prior to release branch cut off will be there. * If Juniper engineering/PMs add a new feature or bug fix to Juniper's Contrail will it get also commited to community XYZ branch ? Juniper will follow upstream process to add feature. Features going to master (expect for maintenance branch specific features) * Who and how will decided what goes into what branch ? TSC controls all branches expect for Juniper release 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 ? There is no 100% parity on features. There should be 100% parity on bugs (eventual consistency). ARB ensures that all community releases and commercial releases are interoperable. But interoperability is limited to ability to upgrade from community to commercial release. There is no provision for running half a deployment using community builds, and half using commercial. We will create a set of requirements for any commercial release not just juniper must provide for upgrade from Community to Commercial without a pod reinstall. * Is Juniper going to internally keep texting community XYZ version ? Juniper will test parts of community build which juniper packages for commercial release. Right now it is 100%. In the future existing UI and existing analytics are not going to be tested by Juniper QA. Juniper will give CI and functional tests. Eventually community and commercial with have distinct QA efforts with a very large degree of overlap. Many thx, Robert.
_______________________________________________ Dev mailing list Dev@lists.opencontrail.org http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
