I think a good start would be a concrete list of the places you felt you needed to change upstream and the specific reasons for each that it wasn't done as part of the community.
For example, I look at your nova fork and it has a "don't allow this call during an upgrade" decorator on many API calls. Why wasn't that done upstream? It doesn't seem overly controversial, so it would be useful to understand the reasoning for that change. To be blunt I had a quick scan of the Nova fork and I don't see much of interest there, but its hard to tell given how things are laid out now. Hence the request for a list. Michael On Thu, May 24, 2018 at 6:36 AM, Dean Troyer <[email protected]> wrote: > On Wed, May 23, 2018 at 2:20 PM, Brian Haley <[email protected]> wrote: > > Even doing that is work - going through changes, finding nuggets, > proposing > > new specs.... I don't think we can expect a project to even go there, it > has > > to be driven by someone already involved in StarlingX, IMHO. > > In the beginning at least it will be. We have prioritized lists for > where we want to start. Once I get the list and commits cleaned up > everyone can look at them and weigh in on our starting point. > > dt > > -- > > Dean Troyer > [email protected] > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Did this email leave you hoping to cause me pain? Good news! Sponsor me in city2surf 2018 and I promise to suffer greatly. http://www.madebymikal.com/city2surf-2018/
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
