Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
On Thu, Aug 10, 2017 at 11:01:23PM +, Jeremy Stanley wrote: > Yes, it comes up often enough and as far as I'm aware reviewers > haven't previously rejected unofficial projects who want to receive > requirements updates. There are definitely projects who don't want > to (or for license reasons perhaps even can't) be official teams but > would still like their dependencies to remain compatible with those > of official OpenStack deliverables. Thanks. I know you aren't suggesting altering the ability for OpenStack Hosted projects to participate in the requirements process but I want to go on the records saying I see having OpenStack Hosted projects syncing from requirements as a big plus and I'd be pretty down on any move to reject them. I'd also resist any process change that makes it harder for Hosted projects (as opposed to Governed projects) to participate in the requirements process. At this point it's hard for the affected teams to even see this thread as there isn't an easy way to identify them. Yours Tony. signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
On 2017-08-11 08:49:18 +1000 (+1000), Tony Breeds wrote: > On Thu, Aug 10, 2017 at 07:22:56PM +0900, Akihiro Motoki wrote: [...] > > 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? > > I didn't think that was the rule but it's certainly been said > enough in the last 24 hours that it probably is correct. > > With that in mind we'd do better if there was a process for > Openstack Hosted projects to follow. > > Perhaps they could maintain a > 'deliverables//.yaml in their own repo that would > mirror (but probably get out od sync with, openstack/releases. > From a requirements POV I just need somewheer to look for data on > the projects that are managed but not official. Yes, it comes up often enough and as far as I'm aware reviewers haven't previously rejected unofficial projects who want to receive requirements updates. There are definitely projects who don't want to (or for license reasons perhaps even can't) be official teams but would still like their dependencies to remain compatible with those of official OpenStack deliverables. -- Jeremy Stanley signature.asc Description: Digital signature __ 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
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
On Fri, Aug 11, 2017 at 12:46:20AM +0900, Ian Y. Choi wrote: > Akihiro Motoki wrote on 8/10/2017 7:22 PM: > > Tony, > > > > Thanks for taking care. > > > > > > > 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. > > > > > Right - i18n repository has I18n contributor guide, translation glossary, > and useful scripts with translate.openstack.org > which all do not need to have stable branches to be maintained. Now that I know what it is I can handle it in my script. That's fine > I am not pretty sure but it seems that some project repositories which are > affected by requirements.txt in stable branches > need to follow "stable:follows-policy" [1] for official projects? No that is a seperate thing. That tag asserts that the code delivered via that repo adheres to the stable policy. What this email thread is about is repos that subscribe to the Yours Tony. signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
On Thu, Aug 10, 2017 at 07:22:56PM +0900, Akihiro Motoki wrote: > 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. Okay I'll added that to the 'branchless' group. > > 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. As long as you block bot-updates from the time we branch (pike) until the time you branch (pike) that is all that needs to happen > > 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. As with the neutron-vpnaas repos, you need to block to bit updates or it *does* block (or hamper) the requirements repo from re-opening master. > > 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? I didn't think that was the rule but it's certainly been said enough in the last 24 hours that it probably is correct. With that in mind we'd do better if there was a process for Openstack Hosted projects to follow. Perhaps they could maintain a 'deliverables//.yaml in their own repo that would mirror (but probably get out od sync with, openstack/releases. From a requirements POV I just need somewheer to look for data on the projects that are managed but not official. Yours Tony. signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
On Thu, Aug 10, 2017 at 10:17:23AM -0400, Matthew Treinish wrote: > On Thu, Aug 10, 2017 at 03:46:32PM +1000, Tony Breeds wrote: > > > > 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-dashboardneutron > > solum-dashboardsolum > > tacker-horizon tacker > > watcher-dashboard watcher > > zun-ui zun > > > > Repos with type: other > > python-openstackclient OpenStackClient > > patroleQuality Assurance > > Fwiw, patrole is also a tempest plugin. [1] So it should also fall into the > branchless category and you don't need to worry about it branching before > unfreezing requirements. \o/ I shall update my script and the tracking document. Thanks. Yours Tony. signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
On Thu, Aug 10, 2017 at 12:38:43PM +0200, Dmitry Tantsur wrote: > Hi Tony! > > I hope to finish releasing Ironic stuff next week. We still have a few > critical things to land. Cool > On 08/10/2017 07:46 AM, Tony Breeds wrote: > > > > 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 > > This was released already. Hmm okay perhaps my repo is out of date. I'll check that. > > manila-ui manila > > monasca-ui monasca > > neutron-fwaas-dashboardneutron > > solum-dashboardsolum > > tacker-horizon tacker > > watcher-dashboard watcher > > zun-ui zun > > > > Repos with type: other > > python-openstackclient OpenStackClient > > patroleQuality Assurance > > heat-agentsheat > > ironic-inspector ironic > > Hmm, this should be type:service too, will double-check. Cool. Thanks. Yours Tony. signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
Akihiro Motoki wrote on 8/10/2017 7:22 PM: Tony, Thanks for taking care. 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. Right - i18n repository has I18n contributor guide, translation glossary, and useful scripts with translate.openstack.org which all do not need to have stable branches to be maintained. I am not pretty sure but it seems that some project repositories which are affected by requirements.txt in stable branches need to follow "stable:follows-policy" [1] for official projects? And also thanks a lot - since I also keep on eyes for having stable branches from translation target repositories in Pike release cycle [2]. With many thanks, /Ian [1] https://governance.openstack.org/tc/reference/tags/stable_follows-policy.html [2] http://git.openstack.org/cgit/openstack/releases/tree/PROCESS.rst#n214 __ 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
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
On Thu, Aug 10, 2017 at 03:46:32PM +1000, Tony Breeds wrote: > > 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-dashboardneutron > solum-dashboardsolum > tacker-horizon tacker > watcher-dashboard watcher > zun-ui zun > > Repos with type: other > python-openstackclient OpenStackClient > patroleQuality Assurance Fwiw, patrole is also a tempest plugin. [1] So it should also fall into the branchless category and you don't need to worry about it branching before unfreezing requirements. -Matt Treinish [1] https://github.com/openstack/patrole/blob/master/README.rst#release-versioning > heat-agentsheat > ironic-inspector ironic > ironic-python-agentironic > kuryr-kubernetes kuryr > monasca-common monasca > monasca-notification monasca > monasca-persister monasca > monasca-transform monasca > > Repos with type: service > ironic ironic > monasca-apimonasca > monasca-log-apimonasca > swift swift > tricircle tricircle > vitragevitrage > watcherwatcher > zunzun > > 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
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
Features for tricircle pike has been freezed, and no exception was asked until now, as you proposed, If neutron can have branch this week, we can cut branch earlier. Thank you, TTX. From: Thierry Carrez [thie...@openstack.org] Sent: 10 August 2017 20:39 To: openstack-dev@lists.openstack.org Subject: Re: [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][winst... joehuang wrote: > Tricircle plans to cut stable/pike branch on August 22nd, it has dependency > on Neutron stable/pike creation. That sounds a bit late to create your release branch. It doesn't give you a lot of time to react to critical issues discovered in that release, as August 24 is the final date to submit new releases for inclusion before Pike is formally declared released. My advice would be to do a X.Y.0 release as soon as you can freeze features (neutron should have their branch this week), and have some time to produce a X.Y.1 bugfix release if you detect critical issues in testing. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
joehuang wrote: > Tricircle plans to cut stable/pike branch on August 22nd, it has dependency > on Neutron stable/pike creation. That sounds a bit late to create your release branch. It doesn't give you a lot of time to react to critical issues discovered in that release, as August 24 is the final date to submit new releases for inclusion before Pike is formally declared released. My advice would be to do a X.Y.0 release as soon as you can freeze features (neutron should have their branch this week), and have some time to produce a X.Y.1 bugfix release if you detect critical issues in testing. -- Thierry Carrez (ttx) __ 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
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
Hi Tony! I hope to finish releasing Ironic stuff next week. We still have a few critical things to land. On 08/10/2017 07:46 AM, Tony Breeds wrote: 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 This was released already. manila-ui manila monasca-ui monasca neutron-fwaas-dashboardneutron solum-dashboardsolum tacker-horizon tacker watcher-dashboard watcher zun-ui zun Repos with type: other python-openstackclient OpenStackClient patroleQuality Assurance heat-agentsheat ironic-inspector ironic Hmm, this should be type:service too, will double-check. ironic-python-agentironic kuryr-kubernetes kuryr monasca-common monasca monasca-notification monasca monasca-persister monasca monasca-transform monasca Repos with type: service ironic ironic monasca-apimonasca monasca-log-apimonasca swift swift tricircle tricircle vitragevitrage watcherwatcher zunzun 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 openstackclientOpenStackClient anchor Security ceilometer-powervm Telemetry ec2-apiec2-api horizon-cisco-ui horizon bifrostironic ironic-python-agent-builderironic 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 (no
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
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 : > > 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-dashboardneutron > solum-dashboardsolum > tacker-horizon tacker > watcher-dashboard watcher > zun-ui zun > > Repos with type: other > python-openstackclient OpenStackClient > patroleQuality Assurance > heat-agentsheat > ironic-inspector ironic > ironic-python-agentironic > kuryr-kubernetes kuryr > monasca-common monasca > monasca-notification monasca > monasca-persister monasca > monasca-transform monasca > > Repos with type: service > ironic ironic > monasca-apimonasca > monasca-log-apimonasca > swift swift > tricircle tricircle > vitragevitrage > watcherwatcher > zunzun > > 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-bl
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
On Thu, Aug 10, 2017 at 08:41:40AM +, joehuang wrote: > Hello, > > Tricircle plans to cut stable/pike branch on August 22nd, it has > dependency on Neutron stable/pike creation. Okay in that case can you block any reviews from the proposal-bot until you do branch. Yours Tony. signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
On Thu, Aug 10, 2017 at 07:29:22AM +, witold.be...@est.fujitsu.com wrote: > Hi Tony, > > stable/pike branches for Monasca repos are on the way > > https://review.openstack.org/492101 Great! next cycle we'll have to try and match against open reviews to reduce the noise. Yours Tony. signature.asc Description: PGP signature __ 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
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
Hello, Tricircle plans to cut stable/pike branch on August 22nd, it has dependency on Neutron stable/pike creation. Best Regards Chaoyi Huang (joehuang) From: Tony Breeds [t...@bakeyournoodle.com] Sent: 10 August 2017 13:46 To: OpenStack Development Mailing List Subject: Re: [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][winst... 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-dashboardneutron solum-dashboardsolum tacker-horizon tacker watcher-dashboard watcher zun-ui zun Repos with type: other python-openstackclient OpenStackClient patroleQuality Assurance heat-agentsheat ironic-inspector ironic ironic-python-agentironic kuryr-kubernetes kuryr monasca-common monasca monasca-notification monasca monasca-persister monasca monasca-transform monasca Repos with type: service ironic ironic monasca-apimonasca monasca-log-apimonasca swift swift tricircle tricircle vitragevitrage watcherwatcher zunzun 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 openstackclientOpenStackClient anchor Security ceilometer-powervm Telemetry ec2-apiec2-api horizon-cisco-ui horizon bifrostironic ironic-python-agent-builderironic 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 rem
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
Hi Tony, stable/pike branches for Monasca repos are on the way https://review.openstack.org/492101 Cheers Witek > -Original Message- > From: Tony Breeds [mailto:t...@bakeyournoodle.com] > Sent: Donnerstag, 10. August 2017 07:47 > To: OpenStack Development Mailing List d...@lists.openstack.org> > Subject: Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality > Assurance][Security][Telemetry][ec2- > api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neu > tron][octavia][senlin][solum][swift][tacker][tricircle][vitrage][watcher][winst > ... > > > 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-dashboardneutron > solum-dashboardsolum > tacker-horizon tacker > watcher-dashboard watcher > zun-ui zun > > Repos with type: other > python-openstackclient OpenStackClient > patroleQuality Assurance > heat-agentsheat > ironic-inspector ironic > ironic-python-agentironic > kuryr-kubernetes kuryr > monasca-common monasca > monasca-notification monasca > monasca-persister monasca > monasca-transform monasca > > Repos with type: service > ironic ironic > monasca-apimonasca > monasca-log-apimonasca > swift swift > tricircle tricircle > vitragevitrage > watcherwatcher > zunzun > > 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 > openstackclientOpenStackClient > anchor Security > ceilometer-powervm Telemetry > ec2-apiec2-api > horizon-cisco-ui horizon > bifrostironic > ironic-python-agent-builderironic > magnum magnum > magnum-ui magnum > manila-image-elements manila > murano-agent murano > octavia-dashboard octavia > senlin-dashboard senlin > tacker tacker > net
Re: [openstack-dev] [requirements][I18n][OpenStackClient][Quality Assurance][Security][Telemetry][ec2-api][heat][horizon][ironic][kuryr][magnum][manila][monasca][murano][neutron][octavia][senlin][solu
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-dashboardneutron solum-dashboardsolum tacker-horizon tacker watcher-dashboard watcher zun-ui zun Repos with type: other python-openstackclient OpenStackClient patroleQuality Assurance heat-agentsheat ironic-inspector ironic ironic-python-agentironic kuryr-kubernetes kuryr monasca-common monasca monasca-notification monasca monasca-persister monasca monasca-transform monasca Repos with type: service ironic ironic monasca-apimonasca monasca-log-apimonasca swift swift tricircle tricircle vitragevitrage watcherwatcher zunzun 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-craton
