During numerous discussions at the Vancouver 2018 Forum,
the topic of discouraging review cultural behaviors came
up repeatedly.
This has come up before, but never to the point where prior
community participants and leaders who took the opportunity
to reconnect with the community came into the room and
explicitly stated that it was the review culture as to
why they left.
The common frustration that was repeatedly raised was having
to revise patches over and over due to varying nitpicks where
negative feedback was left forcing the patch to be updated
in order to gain any additional review feedback.
We recognize that this is counter productive, and that we
need to change our review culture, so we are updating the
principles to express the aspects of peer review that we
value.
Co-Authored-By: Doug Hellmann <doug@doughellmann.com>
Change-Id: I3b615784824de2a15a911780fe8c37928f2c453e
We want to default to running all tox environments under python 3, so
set the basepython value in each environment.
We do not want to specify a minor version number, because we do not
want to have to update the file every time we upgrade python.
We do not want to set the override once in testenv, because that
breaks the more specific versions used in default environments like
py35 and py36.
Change-Id: I13cd6b83388368966868f90ae09c88a3c644114f
Two new roles have been asked by the community: a way to
deploy zun, and a way to use qpid dispatch router instead of
rabbitmq.
This patch includes both new roles, as we usually do:
They will be separate of the openstack-ansible main deliverable,
like other roles before it.
Depends-On: https://review.openstack.org/#/c/572551/
Change-Id: I5fb2f24d2eecd38de793a1e739e14614b488e01d
This is a small python library and utility to monitor the partitions,
volumes and other statistics of AFS servers and report them for
collection. Although there are other AFS monitoring utilities, no
extant projects were found that abstract the data into Python or
support statsd reporting.
Depends-On: https://review.openstack.org/572371
Change-Id: I626fd809502f5df77574c7d70aa7e029a11ecf6b
The openstackclient cookbook supersedes the openstack-client cookbook
for providing Chef resource wrappers around fog-openstack. We want to
include this cookbook to foster contribution and consolidate the
actively developed repos under one place. This will be a deliverable
treated as other maintained cookbooks in Chef OpenStack.
Depends-On: I1512a588897b31984ed72859ee93a89496da07c9
Change-Id: I5eba7be0e57eb02419ca6299fd4e37812e1e4511
Documentation links were removed from the projects.yaml file
with commit fb52d2432793cd7688aa6a8fc115c4ab351b2891.
However a couple of them subsisted as the SDK team was in the
process of being renamed around the same time.
Change-Id: I260968d937692ce234ba8c47d8a5bda3061ff251
The link to the page containing the historical incubation/graduation
requirements is labelled "Requirements for previously-used
incubation/integration process", but the document itself contained no
indication that the content was obsolete.
Add a note indicating the status and linking to the current process.
Change-Id: I51154558a76cda7be5eb8635c9fc938fe132e082
It was pointed out in #openstack-tc[*] that we may be making some
assumptions about the reasons for base services without having fully
expressed them in any durable form. As an example, when we added a
distributed lock manager to this list the driving reason was that
several services had already implemented their own (some completely
independently, some by copying from other services and then perhaps
making modifications). There are times when we solve this problem by
adding new shared libraries, hence the remit of Oslo, but some
solutions need full-blown services in their own right which may or
may not be developed within the OpenStack community.
We also realize that deployments may be hesitant to turn on useful
features by default because they rely on yet another service, and
this hampers adoption of something which if ubiquitous would perhaps
snowball into the addition of similar useful default capabilities
in OpenStack deployments.
[*] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2018-05-16.log.html#t2018-05-16T17:55:51
Change-Id: Ie85658e95dad210ea8ef838eb2fb5a571ed02cab
This role provides a general mechanism to modify existing container
images before or during a TripleO deployment. The main target use
cases are:
- during CI to refresh image packages to test changes
- developer workflows to include code being developed
- third party plugin inclusion to existing images
Change-Id: I13c24af42b765b3dd91abe470d7e23a34540b340
Depends-On: I01dfa1f939181f63e82f8001008c5c9fb89ab866
The os_blazar role is necessary for some deployers, so we
want to include this new role to get new contributions. This will
be as a separate deliverable as the main openstack-ansible project,
like others extra roles before it.
Depends-On: https://review.openstack.org/#/c/566540/
Change-Id: Ife2853269842cdcf4936334f019fee16463a5d80
Newer versions of Sphinx load the extensions before creating any of
the output directories, so the os.mkdir() call in the badge extension
was failing. Fix the problem by tying the badge step to the
build-finished event Sphinx emits when it reaches the end of its
build.
This change also uncaps Sphinx in the requirements file, since that
cap is not honored in the CI job anyway.
Change-Id: Ia6c232c5bc8c4015e00efe0b3b4182da2490acc7
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
