"A pattern, apart from the term's use to mean Template is a discernible regularity in the world or in a manmade design. As such, the elements of a pattern repeat in a predictable manner." -https://en.wikipedia.org/wiki/Pattern
Hello horizon-eers, We have made some progress towards angular development in horizon, but much of it is still invisible. During Kilo, enough effort was put forth on angular work to help us recognize the deficiencies of the existing horizon angular code structure, style, localization, and even directory layout. A lot of effort went into Liberty to improve all of those areas, which has now enabled a much more serious discussion on producing angular based panels for horizon. And we actually have quite a few panels pretty far along in the patch process, but pretty much stuck in a holding pattern. Why? Primarily because there isn’t agreement on the coding pattern to be used for the panels. Everybody seems to agree that we want a good enough pattern to base all the panels on. And most people would like a pattern that provides enough reusable widgets / services / etc that replicating the pattern requires a minimal amount of code with a maximum amount of flexibility. However, one problem is that no single panel on its own constitutes a pattern. And within any line of patches for a particular panel, the attempts to extract out reusable pieces into separate patches often get blocked because they are only used in a single panel. This creates an impasse where the ability to effectively work on panels stagnates. So, right now, the most recognizable pattern for angular panels is release after release of horizon having zero angular panels implemented. That is a pattern that I believe must be broken. So what can we do about it? Here are a few options: 1) Formalize a status of "experimental" and allow a limited number of disabled panels to merge with refactoring allowed 2) Immediately create a relatively short lived "Angular Panel" feature branch for some cross panel work. 3) Establish a new angular repo with additional cores for angular based features with a separate release mechanism One argument says that merging in code that is initially disabled (panel disabled, workflow disabled) at least provides some real examples to draw from and actually can better enable external plugin developers, such as the app catalog work being done. It also can help to identify bugs and usability problems that may not otherwise be discovered (such as hard coded static urls and webroots) because deployers will have access to the feature. If a particular deployer wants to use it, they can enable it, potentially at their own risk. If another deployer does not want to use it until the feature has more time to bake, they do not have to use it and don’t have to block other deployers that do want to use it. A counter argument is that allowing the merge of disabled code allows undesirable patterns to replicate quickly, causing way too much time to be wasted with having to refactor everything. The idea of a feature branch has been brought up before, but I think it was not accepted for a number of reasons. A few being that the scope and goal of such a feature branch was not clear (too narrow or too broad) and with a lack of belief that there would be a reasonable timeline for acceptance back to master. We could also just create a separate repo for the angular based work (framework, dashboards, panels) and perhaps provide that as its own xstatic package (synced up to the main horizon release). A deployer desiring the angular work would deploy that package along with the base horizon release and still be able to selectively enable / disable the angular features they want. The argument against this is that it is more complicated to manage and even more likely that we could break things. In my opinion the most effective route forward is something like this: 1) Immediately create a feature branch for Angular Panel Pattern Establishment 2) Allow 3 - 5 panels and their patches to be eagerly merged 3) Use the panels to establish cross panel patterns and to find ways to simplify code re-use 4) Extract out patches to be proposed to master as we see fit 5) Set a goal of Mitaka M1 for at least a few panels to be merged back to master While on the feature branch, the goal is to promote co-existence and pattern development allowing for easier collaboration between developers. This means allowing incomplete features on the branch. When merged back to master, the reviews would enforce the more stringent standards for merge guidelines, but could still allow for panels to be merged and still initially be disabled if desired. I believe that this would create a pattern of visible progress. Remember, perfection is the enemy of... http://pasteboard.co/zq44Y8f.png -Travis __________________________________________________________________________ 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
