Difference between revisions of "Meetings/Horizon"

Revision as of 15:06, 22 May 2019

The OpenStack Horizon Team holds public meetings in #openstack-meeting-alt, weekly on Wednesdays at 1500 UTC.

See http://eavesdrop.openstack.org/#Horizon_Team_Meeting for recordings of previous meetings and the upcoming meeting schedule.

Everyone is encouraged to attend!

Agenda for Next Meeting

Notices
Action items from the previous meeting
Release Priorities
- https://etherpad.openstack.org/p/horizon-release-priorities
Open Discussion
- ini-based-configuration (amotoki)
  - The planning document needs to be reviewed first. Other
  - how can I move this forward without a ton of rebase?

@@ Line 8: / Line 8: @@
 * Notices
-** use_mox is now disabled by default. it affect horizon plugins.
 * Action items from the previous meeting
+* Release Priorities
+** https://etherpad.openstack.org/p/horizon-release-priorities
 * Open Discussion
-** Needs volunteers on mox->mock conversion https://etherpad.openstack.org/p/horizon-unittest-mock-migration
+** ini-based-configuration (amotoki)
-** How can we gather more contributors on attractive features?
+*** The planning document needs to be reviewed first. Other
-*** example: https://blueprints.launchpad.net/horizon/+spec/multi-attach-volume
+*** how can I move this forward without a ton of rebase?
-** horizon release model: cycle-with-milestone vs cycle-with-intermediary
-*** The infra change (zuulv3 configuration change) [1] now forces horizon plugin developers to handle horizon dependencies in a tricky way.
-**** The OpenStack CI installs horizon master (based on tox-siblings) and it works well, but local testing will fail because it installs horizon queens.
-**** This problem is based on a horizon version published to PyPI.
-**** horizon is a kind of library from perspective of horizon plugins. from this point, it is reasonable to publish horizon with cycle-with-intermediary.
-**** If so, the version of horizon would follow semantic versioning. It would help horizon plugin developers.
-**** However, the versioning might be surprising for horizon consumers like operators/users.
-*** horizon-lib again might be a good candidate on this problem.
-*** [1] http://lists.openstack.org/pipermail/openstack-dev/2018-March/128310.html