Open Stack

I agree with Graham +1

Remo 

> On Jun 5, 2018, at 8:42 AM, Graham Hayes <gr at 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-request at lists.openstack.org <mailto:OpenStack-dev-request at 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-request at lists.openstack.org <mailto:OpenStack-dev-request at 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>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180605/dd19dbfb/attachment-0001.html>