We have the release based runtimes documented in this repo and
published. However, The link to them from within the PTI page is
easily missed. This change adds a specific runtimes index page and
links to that from the reference section of the governance homepage.
The list included in the PTI page uses the default ascii sorting i.e.
2023.1, 2023.2, 2024.1, Stein, ..., Zed
The change also updates this list to follow the release order.
Change-Id: I0b8cd23986f6abb168486f8cf2a8c30e2a1b30e9
According to the PTI it was not clear whether Python versions should
be kept whenever new platform is being adopted.
This change adds recommendation for libraries and other projects
to keep older platforms, including Python.
Change-Id: Ie2bb6c96e39eb21ab42132774699f254c7f476a9
We discussed the upgarde path testing in PTG[1] and agreed to
support two distro version when a release bumping to new version.
Let's document the existing and new testing recommendation for
upgrade in PTI.
Also change the 2023.1 tetsing runtime accordingly.
[1] https://etherpad.opendev.org/p/tc-2023-1-ptg#L422
Change-Id: I829ad6325f92c9162edf61046d3a46cb61e55a09
As discussed in Yoga PTG[1] and centos stream 9
is released, we are updating Yoga testing runtime with:
- Add Debian 11 as tested distro
- Change centos stream 8 -> centos stream 9
- Bump lowest python version to test to 3.8
and highest to python 3.9
[1] https://etherpad.opendev.org/p/tc-yoga-ptg
Change-Id: I2fb3a1daa5ee812ea45bab0c2fb7c0997dc2d116
OpenSUSE is no longer maintained for testing
in OpenStack upstream CI, devstack job is broken
for more than month and unfortunately we do not have
any active maintainer to fix and maintain it.
Devstack team is planning to drop the openSUSE job
- https://review.opendev.org/c/openstack/devstack/+/769884
If we cannot test it with working job then we should remove
it from wallaby and future testing runtime.
Agreement on this in TC meeting (14th Jan 2021)
- http://eavesdrop.openstack.org/meetings/tc/2021/tc.2021-01-14-15.00.log.html#l-226
Change-Id: Ia666cc9e306bbea513e94342e92c45ba4d509d42
There is always confusion on supported linux distro testing
requirement on we need to have all projects need functional
jobs for those distros or devstack and tripleO testing it enough or
not. Example: https://review.opendev.org/#/c/720005
We cannot do each project testing on each distro due to limited
infra and developers bandwidth. Let's clarify the minimum testing
we need to call distro as supported in OpenStack.
Change-Id: I22ceda49c50282ebb72e70c74e5038e828434ed6
Now that we no longer use 'popularity' as a criteria for including
distros in the PTI, there's no need to include a boring disclaimer about
the relative popularity of RHEL vs. CentOS.
Change-Id: I4c566ff4f9d7fa20eb755061af5dae01ac6e8edb
Combine the links in the list and remove the redundant use of "latest"
on each line.
Change-Id: I44c19d0c6c39e6624c76bfdf8a3e433b5e22983b
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
When the Ubuntu and CentOS were added in the PTI as "supported
distros", SUSE was already one of the most-popular distros [1],
and therefore deserves listing here.
I don't believe the PTI should refer to "popular" term for distros,
as this isn't a popularity contest. Instead, we should allow any
distribution where community effort is provided.
In this case, openSUSE images are present in infra, and SUSE contributors
are using devstack on openSUSE. Next to that, deployment projects like
openstack-ansible or openstack-helm are making use of openSUSE.
Last, but not least, some projects already take into account openSUSE
in their regular work (for example, when the nova team contacts the
distributions at the beginning of the cycle to know their latest
supported libvirt [2]).
I believe all these arguments are enough to warrant the addition of
openSUSE in the list of distributions.
[1]: SUSE was ranked 4th in that survey (with SLES), after RHEL (3rd).
[2]: http://lists.openstack.org/pipermail/openstack-dev/2018-September/135007.html
Change-Id: I1ac3b7477b5d4cb4af75c319b4232d20b4b4b284
This adds a PTI section to have an official declaration of
the targeted runtimes for the release. This should also be retroactively
added to other cycle sections so we have a historical record of what was
supported for that release.
Javascript section omitted because I have zero experience with Node and
NPM, but it would be good to expand on this to include all of our
official runtimes.
Change-Id: I11b136a9781dd1a77df536f099df10a6dd524e06
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
As part of planning out the python3 transition we realized that in
order to have a self-testing patch in each repository to switch the
documentation build to use python3, we would need to include some
information in the repository that the job would read to decide which
version of python to use. After considering several options, we
realized that this requirement meant we had set the API for the
documentation jobs at the wrong "level" of the stack.
This patch restores the use of tox for building documentation in the
standard project testing interface. Rather than using the "venv"
environment, it specifies a new environment for "docs", based on the
common pattern we have in most projects to provide that as a
convenience for developers.
The Python-specific notes about adding the environment as a
convenience are removed, since it is now required.
Change-Id: Ibdee118f30972e9dc67952b921f493e9c1a116ff
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
The PTI reference implies that the docs build job will output rendered
documents to doc/build when it is in fact doc/build/html. Fix up the
doc accordingly to avoid confusing the next guy as I myself was
confused.
Change-Id: I7c3e189cb29164c4934e809e5a64e938307fb320
In change Iaa917d4f126d24c701cd3b8b0edfba4d4e0ca9c1 we have the
proposal to not to install releasenotes/requirements.txt as projects
should not really need any extra requirements to produce releasenotes
other than reno itself being installed and available.
Remove the references to this requirements.txt file so the CI
implementation does not get out of sync with policy. As noted by
AJaeger in the other change, not repo uses this as yet.
Change-Id: Ieab3dfde7854d76dded6b1f8dd3aab1f1071b208
Needed-by: Iaa917d4f126d24c701cd3b8b0edfba4d4e0ca9c1
We expect this of OpenStack projects now. Be explicit about it.
Use the same overall structure as is used for Sphinx. Because we expect
reno requirements to be a much more consistent set, make listing them
explicitly in the repo optional. A reno releasenotes job should be able
to know what it needs to install to generate reno docs without any
specific instructions from the repo itself.
Change-Id: I1cfa2216451d056c1bdedd67186131c5e0901ecb
Update our PTI for docs to be more about show Sphinx should operate.
Remove the mention of tox -evenv -- python setup.py build_sphinx which
is super OpenStack specific and ALSO doens't make anything any easier.
Define the Sphinx config and setup and apply it to all of the languages.
Then add a mention of developer-convenience additions for each language.
This should allow us to do sphinx docs one way regardless of language
without adding tox requirements to non-python projects, and to have our
python projects behave in a way consistent with other parts of the
python ecosystem such as readthedocs.
Change-Id: Ief487e1d20ea20facf398367ca03a6385182fb38
When we talk about the PTI, we tend to say "PTI". In fact, the original
filename is "reference/project-testing-interface.rst". However, the
pre-language files use the cti acronym, as do all of the title lines.
Let's align with the acronym people use when discussing the concept.
Also, remove the suffix from the language files - they're in a directory
called "pti" already, they don't need a _pti suffix.
Change-Id: I53bc82eb2cb2125d7446a5f7d0be622118553732
It became clear that Ubuntu and CentOS are the 2 most-popular platforms
when deploying OpenStack.
https://www.openstack.org/assets/survey/April-2016-User-Survey-Report.pdf
We recently saw some cases where some projects implemented some features
that could not work on these platforms.
Example: https://review.openstack.org/#/c/401985/
- A feature in Neutron couldn't work with latest CentOS.
- Neutron and more projects are not gating on CentOS platform, only
Ubuntu.
The goal of this change is to document that we would like to support
Ubuntu and CentOS in our testing and also collaborate with distros when
a dependency is not fresh enough to bring new features in OpenStack.
Change-Id: I8d63a883b29eda2757656008be3c6af83b8f9e88
This patch expands the CTI documentation to support multiple
languages. It creates a single page that describes overall CTI goals,
and then links to documents that go into specifics on each language
supported in OpenStack.
The Javascript section is new, and includes documentation for the
current state of the Javascript CTI. It also explicitly calls out
areas where work needs to be done, in order to encourage
discussion and contributions.
Change-Id: I971b9271443e4fd227b4a6b347dfc385b67eb3e4
Depends-On: I00186c9af441c1778a22379634cdb2f918324bd8
Mentioning Jenkins is over-specification in this document. It is
our current tool, but may not always be. Refer to the CI system
instead.
Change-Id: I4cdf0c08a1a9e456243a687f453917570495c9a6
Several things have changed since last the Project Testing Interface
was approved. It seems like a good idea to formally approve the current
state of the world before suggesting new changes.
Change-Id: Ic933a9dea945e5360d31773baef191fbd5bf436e
This text was approved by the PPB way back in OpenStack's history. There
are several things which have changed and have not been recorded in it,
and there is a new change that should be made. For now, this is verbatim
what was voted on in the past. Changes will follow to update to current
reality.
Change-Id: I9b5e0e5a52aab1d00497d2e8a75e9c9b249a27e9
Tony Breeds