I agree with Graham +1 Remo
> On Jun 5, 2018, at 8:42 AM, Graham Hayes <g...@ham.ie> wrote: > > > > On 30/05/18 21:23, Mohammed Naser wrote: >> Hi everyone: >> >> Over the past week in the summit, there was a lot of discussion >> regarding StarlingX >> and members of the technical commitee had a few productive discussions >> regarding >> the best approach to deal with a proposed new pilot project for >> incubation in the OSF's Edge >> Computing strategic focus area: StarlingX. >> >> If you're not aware, StarlingX includes forks of some OpenStack >> components and other open source software >> which contain certain features that are specific to edge and >> industrial IoT computing use cases. The code >> behind the project is from Wind River (and is used to build a product >> called "Titanium >> Cloud"). >> >> At the moment, the goal of StarlingX hosting their projects on the >> community infrastructure >> is to get the developers used to the Gerrit workflow. The intention >> is to evenutally >> work with upstream teams in order to bring the features and bug fixes which >> are >> specific to the fork back upstream, with an ideal goal of bringing all >> the differences >> upstream. >> >> We've discussed around all the different ways that we can approach >> this and how to >> help the StarlingX team be part of our community. If we can >> succesfully do this, it would >> be a big success for our community as well as our community gaining >> contributors from >> the Wind River team. In an ideal world, it's a win-win. >> >> The plan at the moment is the following: >> - StarlingX will have the first import of code that is not forked, >> simply other software that >> they've developed to help deliver their product. This code can be >> hosted with no problems. >> - StarlingX will generate a list of patches to be brought upstream and >> the StarlingX team >> will work together with upstream teams in order to start backporting >> and upstreaming the >> codebase. Emilien Macchi (EmilienM) and I have volunteered to take >> on the responsibility of >> monitoring the progress upstreaming these patches. >> - StarlingX contains a few forks of other non-OpenStack software. The >> StarlingX team will work >> with the authors of the original projects to ensure that they do not >> mind us hosting a fork >> of their software. If they don't, we'll proceed to host those >> projects. If they prefer >> something else (hosting it themselves, placing it on another hosting >> service, etc.), >> the StarlingX team will work with them in that way. >> >> We discussed approaches for cases where patches aren't acceptable >> upstream, because they >> diverge from the project mission or aren't comprehensive. Ideally all >> of those could be turned >> into acceptable changes that meet both team's criteria. In some cases, >> adding plugin interfaces >> or driver interfaces may be the best alternative. Only as a last >> resort would we retain the >> forks for a long period of time. > > I honestly think that these forks should never be inside the foundation. > If there is a big enough disagreement between project teams and the > fork, we (as the TC of the OpenStack project) and the board (of > *OpenStack* Foundation) should support our current teams, who have > been working in the open. > > There is plenty of companies who would have loved certain features in > OpenStack over the years that an extra driver extension point would > have enabled, but when the upstream team pushed back, they redesigned > the feature to work with the community vision. We should not reward > companies that didn't. > >> From what was brought up, the team from Wind River is hoping to >> on-board roughly 50 new full >> time contributors. In combination with the features that they've >> built that we can hopefully >> upstream, I am hopeful that we can come to a win-win situation for >> everyone in this. >> >> Regards, >> Mohammed >> >> __________________________________________________________________________ >> OpenStack Development Mailing List (not for usage questions) >> Unsubscribe: openstack-dev-requ...@lists.openstack.org >> <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >> <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev> >> > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: openstack-dev-requ...@lists.openstack.org > <mailto:openstack-dev-requ...@lists.openstack.org>?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > <http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev>
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev