On Mon, Oct 3, 2016, at 08:30 AM, gordon chung wrote: > the TC has historically been a reactive council that lets others ask for > change and acts as the final approver. do you believe the TC should be a > proactive committee that initiates change and if yes, to what scope? > more generally, what are some specific issues you'd like the TC address > in the coming year?
Yes, I think the TC should be a proactive committee. I think the OpenStack wide goals work has been a good push towards being more proactive. As for scope I believe the current process of soliciting feedback from the community then picking a small number of achievable goals to focus on per release cycle is a good place to start. Chances are it won't be perfect, but if we don't try something progress can't be made. Then in a cycle look back on what worked and what didn't and refine the process. Ideally OpenStack wide goals should affect the breadth of our projects and users. Specifically goals like becoming python 3 compatible and testing on python 3 are great. CPython 2 has a limited lifetime and OpenStack (not just Nova, Glance, etc) needs to be planning ahead to deal with this. It isn't something that can happen overnight and we should agree on a common plan to address this so that we don't end up with some projects doing Python 3 and others doing PyPy* to the detriment of our developers and users. Another example of a place where project wide goals make sense is in ensuring that OpenStack runs and is tested on newer distro releases as they become available. OpenStack isn't deployed in a vacuum and we should do what we can to make sure that the barriers to deployment don't begin at "can't deploy OpenStack on the distro most people are trying to deploy OpenStack on". In the past we have done a reasonable job at uplifting OpenStack onto new distro releases and making sure the tests run properly. The recent Trusty to Xenial transition has been somewhat painful though. Part of that is probably my fault, but we should stop expecting magical gnomes to do all the work for OpenStack and call it out as an explicit goal in the future for all of OpenStack. As a user of OpenStack clouds I would also like to see more push for a consistent experience as presented to our end users. Tons of work has been done to make this much better than it was a few years ago, but there is so much more we can do. It would make me so happy if we could make OpenStack useable without knowledge of the underlying cloud implementation choices. This actually ends up being problematic due to many small issues so I am not sure if this makes sense as an OpenStack wide goal, but it should illustrate the level at which I think the TC should be proactive. * I have nothing against PyPy and this shouldn't be interpreted as an argument against using it beyond CPython 2's end of life, but I think that we need to solve large scale problems like this consistently so that developers, operators, and our users don't have to juggle a half dozen toolsets to get anything done with OpenStack. Hope this helps, Clark __________________________________________________________________________ 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