[openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winstackers][zun] Help needed
Akihiro Motoki
amotoki at gmail.com
Thu Aug 10 10:22:56 UTC 2017
Tony,
Thanks for taking care.
> The following repos don't seem to use the openstack/releases repo so I
> have less information there.
Most of them are projects not under the governance (so-called "hosted"
or "unofficial" projects),
so I am not sure there is a good way to handle them.
I can comment some of them which I am involved in deeply.
> i18n I18n
At now, i18n repo is a part of governance but this is a project which
has no need to cut a release,
so it always follows the master branch of the requirements repo.
It is not a blocker for opening the master branch in the requirements repo.
> neutron-vpnaas
> neutron-vpnaas-dashboard
These projects are neutron related and horizon plugin.
We will do same things for other neutron stadium and horizon plugin projects.
IMHO we don't need to take care of them much.
> python-openstacksdk
python-openstackclient depends on this, so we need to cut stable/branch
from the latest release. The status of the project is being discussed
in the ML thread,
but I believe we need to cut a stable branch. On the other hand, I
think it does not
block the opening of the master of the requirements repo as the latest
release of
python-openstacksdk is enough for Pike release of OSC.
> It'd be great to get some of these repos represented in
> openstack/releases. Having a confirmed release-model would go a long
> way to clearing up the list. An alternate approach would be to remove
> redundant items from projects.txt
I am not sure that projects not under the TC governance can use
openstack/releases repo.
Is the openstack/release repo for projects under the governance?
Thanks,
Akihiro
2017-08-10 14:46 GMT+09:00 Tony Breeds <tony at bakeyournoodle.com>:
>
> Hi All,
> In an effort to qualify which projects are likley to be affected if
> when we open the requirements repo I generated a list of all repos that:
>
> 1. Subscribe to requirements management
> 2. Do not already have a stable/pike branch
> 3. Do not follow the cycle-with-milestones, cycle-trailing or
> independent release models
> 4. Are not a 'branchless' project (tempest or tempest-plugin)
>
> These repos I believe *should* have a stable/pike branch or will see
> problems when we open openstack/requirements. Those issues were
> described in [1]
>
> It turns out close to 1/3rd of projects that subscribe to requirements
> management are not ready for us to re-open for master. So we need you
> help to get that number down to a much more acceptable number.
>
> The good news is it's pretty easy to fix this with the cool tools and
> workflow in the releases repo[2]. I suspect that the 'service' will
> take care of themselves, and the horizon-plugins are waiting to horizon
> to cut RC1.
>
> Repos with type: horizon-plugin
> ironic-ui ironic
> manila-ui manila
> monasca-ui monasca
> neutron-fwaas-dashboard neutron
> solum-dashboard solum
> tacker-horizon tacker
> watcher-dashboard watcher
> zun-ui zun
>
> Repos with type: other
> python-openstackclient OpenStackClient
> patrole Quality Assurance
> heat-agents heat
> ironic-inspector ironic
> ironic-python-agent ironic
> kuryr-kubernetes kuryr
> monasca-common monasca
> monasca-notification monasca
> monasca-persister monasca
> monasca-transform monasca
>
> Repos with type: service
> ironic ironic
> monasca-api monasca
> monasca-log-api monasca
> swift swift
> tricircle tricircle
> vitrage vitrage
> watcher watcher
> zun zun
>
> Those are the easy items.
>
> The following repos don't seem to use the openstack/releases repo so I
> have less information there.
>
> i18n I18n
> almanach
> blazar
> blazar-nova
> compute-hyperv
> ekko
> gce-api
> glare
> ironic-staging-drivers
> kosmos
> masakari
> masakari-monitors
> mixmatch
> mogan
> nemesis
> networking-dpm
> networking-fujitsu
> networking-generic-switch
> networking-l2gw
> networking-powervm
> neutron-vpnaas
> neutron-vpnaas-dashboard
> nova-dpm
> nova-lxd
> nova-powervm
> os-xenapi
> python-blazarclient
> python-cratonclient
> python-glareclient
> python-kingbirdclient
> python-masakariclient
> python-moganclient
> python-oneviewclient
> python-openstacksdk
> python-valenceclient
> swauth
> tap-as-a-service
> trio2o
> valence
> vmware-nsx
> vmware-nsxlib
> openstackclient OpenStackClient
> anchor Security
> ceilometer-powervm Telemetry
> ec2-api ec2-api
> horizon-cisco-ui horizon
> bifrost ironic
> ironic-python-agent-builder ironic
> magnum magnum
> magnum-ui magnum
> manila-image-elements manila
> murano-agent murano
> octavia-dashboard octavia
> senlin-dashboard senlin
> tacker tacker
> networking-hyperv winstackers
>
> It'd be great to get some of these repos represented in
> openstack/releases. Having a confirmed release-model would go a long
> way to clearing up the list. An alternate approach would be to remove
> redundant items from projects.txt
>
> Yours Tony.
>
> [1] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120720.html
> [2] http://lists.openstack.org/pipermail/openstack-dev/2017-August/120816.html
>
> __________________________________________________________________________
> 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
>
More information about the OpenStack-dev
mailing list