Open Stack

Personally, I¹d still vote for feature branching: I¹d really love to see
an Angular Panels feature branch worked on separately and then merged back
in; effectively, Travis¹ 2nd option. Pick 3(?) panels, like Users, Images,
and the System Information one I¹ve seen around, iterate quickly, merge in
M-1/M-2. There¹s not really any risk there, and it¹s very easy for people
to toggle on or off in their existing workflows. Also, there isn¹t any
spin up time in terms of setting up new repos and adding new core groups
through infra etc. The ideal time to do this would be at the start of the
cycle, too.

New repos sounds like too big a split, and I¹m worried about where that
leaves the community as a whole. Also, I¹m failing to see how mixing the
angular work in with plugin challenges is going to speed to it upŠ sounds
like a bit of a recipe for disaster, IMO. We should keep those concerns
separate for now; there are multiple plugins being written in both
AngularJS and Python already, so I think issues will arise organically as
is.

Rob



On 09/10/2015 21:35, "Tripp, Travis S" <travis.tripp at hpe.com> wrote:

>Hi Doug!
>
>I think the is a great discussion topic and you summarize your points
>very nicely!
>
> I wish you¹d responded to this thread, though:
>https://openstack.nimeyo.com/58582/openstack-dev-horizon-patterns-for-angu
>lar-panels, because it is talking about the same problem. This is option
>3 I mentioned there and I do think this is still a viable option to
>consider, but we should discuss all the options.
>
>Please consider that thread as my initial response to your emailŠ and
>let¹s keep discussing!
>
>Thanks,
>Travis
>
>From: Douglas Fish
>Reply-To: OpenStack List
>Date: Friday, October 9, 2015 at 8:42 AM
>To: OpenStack List
>Subject: [openstack-dev] [Horizon] Suggestions for handling new panels
>and refactors in the future
>
>I have two suggestions for handling both new panels and refactoring
>existing panels that I think could benefit us in the future:
>1) When we are creating a panel that's a major refactor of an existing it
>should be a new separate panel, not a direct code replacement of the
>existing panel
>2) New panels (include the refactors of existing panels) should be
>developed in an out of tree gerrit repository.
>
>Why make refactors a separate panel?
>
>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.
>
>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.
>
>Why build refactors and new panels out of tree?
>
>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.
>
>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.
>
>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.
>
>Looking forward to further discussion and other ideas on this!
>
>Doug Fish
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev