The openstack/releases repository is open for all official deliverables
(including stable releases for previous cycles), not just
release-with-milestone ones, and we are expected to update the repo in
addition to pushing signed git tags.
http://lists.openstack.org/pipermail/openstack-dev/2016-May/095225.html
With that, streamlined the release request process to avoid Launchpad
from the release scheme: new release requests are tracked and managed in
gerrit only. A new request now starts with a patch for
openstack/releases that should be handled by neutron-release team
members and approved by release liaison before merged by global
OpenStack release team.
Branch creation/expiration is still funneled through LP.
While at it, also suggest switching version numbering to SemVer at
earliest convenience.
Change-Id: Ifcae4b596bc27f7fc8a315e3807144ea03fbb83c
We start to maintain the networking API reference in our repo
(neutron-lib), so we need a way to tag bugs related to API ref.
Change-Id: Iea53cc9675d79de1a812782b191e66468dd3c4cb
It is usual that a bug is reported to released versions
of neutronclient and this tag does not make sense in general.
released-neutronclient was originally used to indicate that
bugs tagged with this tag have been fixed in a released version
though they are in 'Fix Committed' status. This tag was introduced
because launchpad sometimes times out when we tried to mark bugs
as 'Fix Released' and there is no way to distinguish them from
bugs fixed in an unreleased neutronclient.
Note that there is no open bugs tagged with the tag now,
so we can remove this tag safely.
Change-Id: Ibd0452a57bca1fee79a5fb8e52d116262cd0f256
Since we are moving to manage in-tree tempest tests, it makes sense to
introduce a new tag for tempest.
Change-Id: I347b4066cb97ad49493340f56c72deec0c2a3221
Based on changes in Keystone we try to unify naming across the projects.
Change-Id: I9fb3a9aa32b9834cb7bd7ae651c75939a0f5f687
Partially-Implements: blueprint keystone-v3
As Paul has stepped away from VPNaaS, putting my and
John's names in as contacts so bugs have someplace to go.
Change-Id: I1ee749367e22996e7a24a06310f8559aace8a709
Signed-off-by: Ryan Moats <rmoats@us.ibm.com>
IPv6 issues can cover many areas from the API down to agents and
wiring. Add a couple of people to the tag to cover more things.
Change-Id: I1b9f3669f92f4590d1bf21a6d90c3b323b725c3f
Below devref documents are updated for the newly created repository.
* bugs.rst
* neutron-teams.rst
* sub_projects.rst
Change-Id: Ia210109be80a4856a7ee9138e42d05ff6bf95f8a
The document is hopefully a good start and will eventually collect
enough information and tips for next release managers to run the
nervous process more smoothly.
Change-Id: Iaa14d818ae13e7cfa5ad061a2ae9d87a1f0fd331
During the past cycle we assumed that only RFEs with
specs were going to get a blueprint page, and hence
an approver/assignee couple. To avoid confusion and
ensure that even spec-less RFEs get enough attention
this process change proposes to treat RFEs the same
way irrespective of its design needs.
Change-Id: Idd1440267dccf84be884adbafe75461c686a8dd0
We need to become more diligent and rigorous about the options and/or
system behaviors that we deprecate. We need to watch for field's
feedback and ensure that we provide an alternative route once a
deprecation is followed up by a removal.
Right now, there's no way to have a comprehensive view of what has
been deprecated in a cycle and what removals have to happen. Adding
this tag is the first step to get this sorted.
Change-Id: Id25ed35c8a23c0e6f6fc1b47545c8d1bab3e8dc7
- Updating links to Neutron and NeutronClient bugs site
- Adding information how to deal with doc bugs
Change-Id: I696061ac2d1a0c62877f5ab2322355c531d3e6f9
Based on my experience as the Neutron Bug Deputy, I would like to add
some extra information to the Bug Deputy directions, so that later Bug
Deputies will be well prepared.
Change-Id: I3ddae7b6af082acb66218253e27da1f709cbd7b7
This patch adds an additional piece of criteria for Neutron sub-projects.
Projects that interface with Neutron on REST API boundaries only should
probably be separate. We propose Kuryr be split out based on this criteria.
We also document why Octavia stays for now.
Change-Id: Ic161409f6d1ca2efb623d9c7c2797d158a8094df
Signed-off-by: Russell Bryant <rbryant@redhat.com>
There has been a lot of discussion about how the current "Neutron
stadium" is working out. Consensus seems to be that it has grown
quickly beyond what makes sense as a single official OpenStack team.
The first step for scaling things back is agreeing on some additional
inclusion criteria that helps with drawing the line for what should be
an independent OpenStack project. See the following thread on the
mailing list for detailed discussion about this:
http://lists.openstack.org/pipermail/openstack-dev/2015-December/080865.html
This patch applies the first piece of criteria that can be used to decide if a
sub-project should be a separate OpenStack Project team. It also applies
the criteria against existing repos under Neutron.
Change-Id: I2f0198ba3174aacbe6b3098074f8c03cffd49438
Signed-off-by: Russell Bryant <rbryant@redhat.com>
These were from a time long since past, and turned out not be useful
even then.
Change-Id: Ic524f10e414e08010804092f72a114de93681e5c
Signed-off-by: Kyle Mestery <mestery@mestery.com>
The OPNFV project [1] is a reference implementation of the
ETSI NFV architecture built on open source components.
OpenStack, and Neutron in particular, are key elements of
this story, and many requirements and issues are driven and
submitted by OPNFV folks that work in both communities.
This tag makes sure that we can keep all of them together for
tracking purposes.
[1] http://superuser.openstack.org/articles/openstack-and-opnfv-strengthen-collaboration-for-telcos
Change-Id: Ie1675ef6f177558f579097fe035494b9380232d0
The rationale is that we would have a single tag to track all
bugs that are about admin and user ease of use, logging quality,
and debuggability.
Change-Id: Ie42e08c924c9e742bdc6d9f4b68bdfbd1a622ba4
Below changes are done as part of this patch.
* Mention about ONOS l3 support.
* Proposing Mr. Albert Dongfeng as a lieutenant for networking-onos.
Change-Id: I87827b08ed868f68cbd49c1fa7b91352d3c46605
Some small changes - since the original paragraph didn't mention that
core is not required until the very last sentence.
Change-Id: I113371933754c109247c5f2b789cda135dce8563