<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" >I have two suggestions for handling both new panels and refactoring existing panels that I think could benefit us in the future:</div>
<div dir="ltr" >1) When we are creating a panel that's a major refactor of an existing it should be a <em>new</em> separate panel, not a direct code replacement of the existing panel</div>
<div dir="ltr" >2) New panels (include the refactors of existing panels) should be developed in an out of tree gerrit repository.</div>
<div dir="ltr" > </div>
<div dir="ltr" >Why make refactors a separate panel?</div>
<div dir="ltr" > </div>
<div dir="ltr" >I was taken a bit off guard after we merged the Network Topology->Curvature improvement: this was a surprise to some people outside of the Horizon community (though it had been discussed within Horizon for as long as I've been on the project). In retrospect, I think it would have been better to keep both the old Network Topology and new curvature based topology in our Horizon codebase. Doing so would have allowed operators to perform A-B/ Red-Black testing if they weren't immediately convinced of the awesomeness of the panel. It also would have allowed anyone with a customization of the Network Topology panel to have some time to configure their Horizon instance to continue to use the Legacy panel while they updated their customization to work with the new panel.</div>
<div dir="ltr" > </div>
<div dir="ltr" >Perhaps we should treat panels more like an API element and take them through a deprecation cycle before removing them completely. Giving time for customizers to update their code is going to be especially important as we build angular replacements for python panels. While we have much better plugin support for angular there is still a learning curve for those developers.</div>
<div dir="ltr" > </div>
<div dir="ltr" >Why build refactors and new panels out of tree?</div>
<div dir="ltr" > </div>
<div dir="ltr" >First off, it appears to me trying to build new panels in tree has been fairly painful. I've seen big long lived patches pushed along without being merged. It's quite acceptable and expected to quickly merge half-complete patches into a brand new repository - but you can't behave that way working in tree in Horizon. Horizon needs to be kept production/operator ready. External repositories do not. Merging code quickly can ease collaboration and avoid this kind of long lived patch set.</div>
<div dir="ltr" > </div>
<div dir="ltr" >Secondly, keeping new panels/plugins in a separate repository decentralizes decisions about which panels are "ready" and which aren't. If one group feels a plugin is "ready" they can make it their default version of the panel, and perhaps put resources toward translating it. If we develop these panels in-tree we need to make a common decision about what "ready" means - and once it's in everyone who wants a translated Horizon will need to translate it.</div>
<div dir="ltr" > </div>
<div dir="ltr" >Finally, I believe developing new panels out of tree will help improve our plugin support in Horizon. It's this whole "eating your own dog food" idea. As soon as we start using our own Horizon plugin mechanism for our own development we are going to become aware of it's shortcomings (like quotas) and will be sufficiently motivated to fix them.</div>
<div dir="ltr" > </div>
<div dir="ltr" >Looking forward to further discussion and other ideas on this!</div>
<div dir="ltr" ><br>Doug Fish</div></div><BR>