Throughout the doc we've used different combinations of words to
express same thing:
* release number
* version number
Also in some places we've used `release name` when intention was to
set number as a guidance.
Now doc is aligned to use `release number` constently.
Change-Id: I952332333d1564012887c560edd46fb7cd90bd15
This was reverted under the understanding it was a fast-track change; it was not and therefore needs a separate formal-vote to change.
This reverts commit fdc25d3ceb.
Change-Id: Ibe5e4474f8e34c4d000c8e2576e685441beecad0
OpenStack introduced some time ago new system of the version
identification. This patch adds some more detailed guidelines
about how it should be used by project teams.
Change-Id: I0b42b2e7bb998026b48f3d5cbd1dcd3463a0058d
Since 2010, we went from 26 different OpenStack releases names
(from "A" - "Austin" to "Z" - "Zed"). It's now time to define an
unambiguous and sustainable release schema to easily identify
different OpenStack releases without taking into account the alphabet
iteration.
With this change the TC proposes to move the release identification
from only a release name (ex: "Axxxx") to "year"."release count within
the year" "release name" (ex: 2023.1 Axxxx). This will help to bring
more clarity for releases support and future feature deprecations.
The release name will continue to be used for marketing purposes and
community engagement. The same release name process and criteria will
continue to be used. When the end of the alphabet is reached we start
again from the first letter of the alphabet (after "Z", the next
name should start with "A" again).
The release number of each individual project is independent of the
release identification/name.
Change-Id: I595504a101138ee4a2afd358dc4af8f6617aa845
This kicks off the naming for the X release. This follows the newer
process to allow any name that begins with the appropriate
letter.
Name nominations will use the pattern we have established and are
detailed in:
https://wiki.openstack.org/wiki/Release_Naming/X_Proposals
Change-Id: If90ef7ca5440a1d089b507b363ed0e03403fe2da
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
We list the release name polling information details in a table, but no
where do we actually provide either the results or links to the results
for someone looking at the release naming process.
This updates the table to link the release letters to the mailing list
announcements declaring the winner of the poll.
Change-Id: Ib583f238134e90828d3be06c047938d7855889ec
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
This kicks off the naming for the W release. This is the first release
that broadens the scope of release names from being restricted to the
geogrphic region, to allowing any name that begins with the appropriate
letter.
Name nominations will use the pattern we have established and are
detailed in:
https://wiki.openstack.org/wiki/Release_Naming/W_Proposals
Change-Id: I33c561645165dd30866e2f1827c8310d3a46306a
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
Names can (and should) be proposed by the community, and the TC will then
rank them, and the process can continue as before.
This patch also removes the requirement to tie the name to a geographic
location for events that may or may not happen in line with the cycles.
Change-Id: Ie7d26312628bb7d26bcba39ec24213b3a08b6793
Signed-off-by: Graham Hayes <gr@ham.ie>
We have had several proposals for changing the release
naming process, but have yet to find one that has
agreement that would be better than the current process.
Until we decide on a new naming scheme, we should
continue the process in place. This kicks off the
naming for the V release that will be based on the
collaboration event that will take place in Vancouver
since we will no longer have a Summit event.
Name nominations will use the pattern we have established
and are detailed in:
https://wiki.openstack.org/wiki/Release_Naming/V_Proposals
Change-Id: Ibf3ebb585174aaf5e3e428ce0674f46aa8380dc2
Signed-off-by: Sean McGinnis <sean.mcginnis@gmail.com>
The fourth release name criterion arguably implies that generic names of
types of geographic features are not eligible, but is ambiguous and has
been the source of confusion. Reduce this by stating it explicitly.
Arguably this rule would have required an exception to be granted for
Pike, and thus could be considered a change in policy (though
interpretations on this seem to differ based on whether you are from
Boston or not).
Change-Id: I158a32b76aee559c194a4bcafa1482e0426e87f3
The actual conduct of the release naming process has diverged from that
which is documented. Bring them back into alignment by giving the naming
co-ordinator and the TC an explicit role in removing names that aren't
in line with the Code of Conduct's injunction to be considerate of our
global audience, prior to their inclusion in the poll.
Change-Id: I4a4b17bbbe2e3168c70b67594639946895ff4d1f
Tony has indicated in the review for
https://review.opendev.org/#/c/674465/ that he would prefer to have
his name removed as polling coordinator.
Add Rico, who volunteer to be naming poll coordinator
Change-Id: I4dd637d0db02b7ecbd9c2d2a63827f11afa93efb
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
We've obviously missed the dates for the U naming poll, so let's
update the schedule.
Change-Id: I00b67e50fa9cedeaec7b6a0d3486460ec201bf65
Signed-off-by: Doug Hellmann <doug@doughellmann.com>
The language in the table is a little cumbersome.
Use `China` to include all regions, cities, or provinces
Change-Id: Ic1c951a6a6977efd0ed394d15d4788f49e477751
The release naming poll will be communicated on openstack-discuss,
as it replaced the openstack, openstack-dev and openstack-operators
mailing lists in 2018.
Change-Id: I813e323889d17fc655993dc80c3a7444eaa95f83
In order to accommodate the challenges of naming a 'U' release in China
some specific clarifications for acceptable names and geographic region
have been defined. I believe these are well within the spirit of the
existing criteria.
Specifically:
* Spelling. Currently, the most popular system of romanization of Mandarin
is the Hanyu Pinyin. Unfortunately, Hanyu Pinyin does not produce any
romanization which begins with the letter U. In order to allow for U
names, romanizations produced by other recognized systems shall be
admissible. For the sake of precision, the accepted systems shall be
Hanyu Pinyin [PY] (official system of China since 1958), Gwoyeu Romatzyh
[GR] (official system of China 1929-1958), Wade–Giles romanization, and
Yale romanization. In practice, only the Gwoyeu Romatzyh system produces
words starting with the letter U. Reference:
http://pinyin.info/romanization/compare/gwoyeu_romatzyh.html
* In addition to the romanized names produced by one of the recognized
romanization systems, traditional and customary spellings of names are also admissible.
We've also defined the geographic region as:
1 The municipality of Shanghai. (Note that Shanghai, being a top level
administrative division of China, is not part of a province. See
https://en.wikipedia.org/wiki/Direct-administered_municipalities_of_China#Current_PRC_municipalities
2 All top level administrative divisions of China which borders Shanghai.
(Jiangsu, Zhejiang)
3 All All top level administrative divisions of China which borders those in
2 above. (Shandong, Anhui, Jiangxi, Fujian)
Eric Kao has kindly volunteered to provide cultural and language
knowledge. Thanks Eric.
The timing of this poll is a little different in that I've allowed 1
week between the nominations period closing and the opening of voting.
This is to ensure that there is adequate time to translate the poll and
ensure that all candidate names are correctly classified.
Change-Id: I3f7f64a2a2a6c244fbecb381228c1c1827d79673
We're approaching the time when it'd be good to know what the T release
will be. Personally I'd like to finalise the election dates for the T
cycle.
I'm happy to coordinate this. The nomination period is a little longer
than most as I'm going to be in PTO for most of that month. I figured
giving things a little longer wont hurt but I'm also happy to let other
handle this if they want.
Change-Id: I3fff48c3b72608aaa14d18c65a0aa339c2f9362d
As for the release before, let's use the location of the upcoming
Berlin summit to help name the S release. We've selected the state of
Berlin as our region!
Change-Id: I294ad5c5bb405e36aa3784d9baf13398b60422d4
Signed-off-by: Paul Belanger <pabelanger@redhat.com>
Release naming polls originally were conducted as public polls
in Launchpad (requiring only a Launchpad account). Then we moved
to CIVS-driven Condorcet polls, with personal voting links to
all Foundation members (requiring a Foundation membership to vote).
Due to limitations in the CIVS service, it's currently not practical
to send Condorcet voting links to every Foundation member. Instead
we'll use the public voting feature of CIVS, and allow anyone with
the link to cast their vote.
That opens the vote to ballot stuffing, but the choice is not that
critical, the proposed names all follow strict criteria, and there
are many safeguards in place to exclude bad names (from a legal or
marketing standpoint). So it feels safe enough to use public voting,
originally disseminating the voting URL through the openstack
mailing-lists.
Change-Id: I2f4b7fb24ccfb54403d0dedc0a757af3c6769d61
And we've come full circle. It was the last Vancouver Summit which was
the impetus for instituting this process. Let's name an OpenStack
release after the Canadian province that Vancouver is in!
Change-Id: I0d2a198fb39acc97fce433791b0f0239bcbba71f
Monty is a really bad person and did not actually do the naming polls on
the previously agreed upon schedule.
Change-Id: I86ac08d73faf57de023cfe5fd6656648427d2f1a
This isn't actually a change in policy - it's just a change in wording
which describes the current situation more precisely.
Change-Id: Id116f40e1d76a170767510506782521e0c08ee26
We don't use date-based numbers anymore. However, it's not really
necessary to expand on how our version numbers works in the document
about naming.
Change-Id: I1205a35b9b788a2af24c440976fb7292484c007a
We know the locations of N and O, so we should pick names.
Follow on patches will fill in geography.
Change-Id: I9801d517681d727b3ac682dea027d6d09ab5f88d
There is no reason to hold off on naming releases one we know their
location. And holding off on release naming is more likely to create
confusion where the dev community just picks a placeholder, uses it in
communication, and that placeholder is wrong later.
Especially as projects are now moving into a phase of planning for
multiple releases in advance for larger efforts, the current
restriction just adds confusion and cleanup work later.
Change-Id: Ife143447ff4a6d2d85260fd9d889853863eff272
The existing relase name criteria were intentionally vague about
geography to allow us to collect the largest amount of cool names
possible for voting. Somehow, that did not end up happening and
instead a specific determination of region was used to drop about
2/3 of the otherwise-qualifying names from the M name poll after
nominations were closed.
In order to prevent this from happening again, we will need to
very specifically designate a region upon initiating the process.
Also, provide clear indication that the role of the election
official is not to make subjective determinations.
Also, allow for a time between finalizing the list of names and
the start of the election so that if the election official makes
any disputed decisions, there is an opportunity to address them
before the poll goes out. This also clarifies when the TC should
add any exceptions to the process.
Finally, add an extra column to the election roster to indicate
where the geographic boundaries should be specified.
For more background, see:
http://lists.openstack.org/pipermail/openstack-dev/2015-June/066995.html
Change-Id: Ia9adc66090f2994bb291967f7f2e1b2b4dd14603
Identify Monty Taylor as the election coordinator for the M release
naming poll and establish the dates for the election.
Change-Id: I169fcb3bf488862488006b556ee4c0bbf4977101
This is generally based on our current process, but makes it clear
that the release name is entirely selected by the community.
Change-Id: Ibd2c6060da2742dd62bbb121a80e6cbfeabedcd0
Dmitriy Rabotyagov