Excerpts from Doug Wiegley's message of 2016-06-20 10:40:56 -0600: > So, it sounds like you’ve just described the job of the TC. And they have so > far refused to define OpenStack, leading to a series of derivative decisions > that seem … inconsistent over time. > > How is this body going to be different? > > How will it have any teeth, and not just end up with the standard entrenched > projects ignoring it? >
Hi Doug, thanks for your candid reply. I understand that there is a concern and I want to address it. However, I feel like answering this directly will start this working group out on the wrong foot. We shouldn't need teeth. This isn't an adversarial working group that will be challenging engineers any more than an architect of a building challenges the builders while they work. An architect that ignores their engineers is not going to complete many projects. Of course, engineers may disagree on the cost of an architectural decision. But to disagree, first we need to actually _make_ a decision on a design. The goal of this group would be to provide a detailed architecture and plans for the way the system should work and fit together as a whole. Like any complex system, during implementation, things that architects weren't aware of come to light. Something that seems simple turns out to be complex. Something that seemed absolutely necessary can be factored out. Nobody is suggesting designing OpenStack from the ground up, just that where there isn't an agreed upon design, let's write down how the system works now, and then make a design and a plan to actually improve it. Engineers have no effective place to turn to right now when there is a lack of design. The TC could of course do it, but what I want to do is have a more open and free-flowing group that are laser focused on providing support for the design of the system. I want to work out with the community at large how we add weight to the designs we choose, and one good option is for the Architecture Working Group to make proposals to the openstack-specs repo, which the TC would ultimately approve. That's not a new process, we already have it: http://docs.openstack.org/project-team-guide/cross-project.html I'm just suggesting a group that actually _focuses_ on the design aspects of that process. Without this, we are designing in real time and taking the shortest path to achieve short term goals. This has positive and negative effects. I think we've reached a point in OpenStack's evolution where the positive effects of that are mostly realized, and now we should work to pay down some of the negative effects by adopting some designs and beginning refactoring of the system. It's not a fast process, so the longer we wait, the longer we pay interest on that debt. __________________________________________________________________________ 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