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 <t...@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-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

__________________________________________________________________________
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

Reply via email to