Moving project lists for election to "PTL Election Details"
section and describe TC candidates information on "TC Election Details"
section.
Change-Id: If80fae88e375ddb4f94d8451fb93446d55217c3c
During the transition from OpenStackID to OpenInfraID, some aspects
of the backend "summit" API changed. Historical affiliations ceased
to be reflected in the "affiliations" array, and now need to be
extracted from "all_affiliations" instead. Further, organization
names are not included unless "all_affiliations.organization" is
expanded.
Change-Id: If6260e6a44fd66ab5df8aa207cb8f4f4bb6ef220
When constructing the description there is trainling whitespace *and*
leading whitespace. This is redundant.
Change-Id: I84f2fbc5daed10b34b8e2285f7ead7bffd6d8c52
CIVS opt-in needs to be announced before voting kickoff so that
electorates participate in voting.
Creating template named: "voting_optin_civs".
Change-Id: I778ee2fcbcdd85599db3ec53c68fc1e6563d92df
Currently we're reverse sorting with a simple sort, this sadly puts
newer released (antalope, bobcat) at the end of the list. Add a
key function that has context around our release names and release ids
to sort "2024.1/cantaloupe"[1] at the top.
[1] As of now the c name isn't selected cantaloupe is my placeholder
Change-Id: Ie7a9ffcdbe6a28cd2a80289ec06259ec869d306f
Currently there are 2 leadership types "distributed" and the
Default/unspecified which we treat as the long established PTL model.
Projects that have selected to use the "distributed" model do not
require a PTL election and in fact projects under this model should
reject a PTL nomination as the correct process involves a change the
governance repo.
This change updates 'create-directories' to exclude those projects,
and also updates the ci checks to fail PTL nominations for "distributed"
projects.
Change-Id: Ib4a2ce1e4ee74e8e9a49975017e14172b4d1f576
When we start the election configuration for dates and
other deadlines, we use the dummy tag generated with election
month and which gets updated once governance release the
actual tag of semver. It is confusing that initial tag
generated by setup_election_config cmd is actual tag or just
a placeholder.
Governance repo has switched to semver type tag since 2018
- https://github.com/openstack/governance/tags?after=oct-2017-elections
Election repo started the below process since 2019:
1. Add placeholder/dummy tag in election config (election month tag generated by script)
- https://review.opendev.org/c/openstack/election/+/661673
2. On email_deadline, release a new tag of governance repo
- https://review.opendev.org/c/openstack/releases/+/680691
3. Update the released tag in election config
- https://review.opendev.org/c/openstack/election/+/681274
This commit does not change the existing process and make the placeholder tag more
clear so that we know that we need to release a new tag in governance at the email_deadline
and update here.
Change-Id: Id8d5e4689ad2374a197e63e7fb41c6b5c265ff5c
Most of the election tooling work on seperate events
of PTL and TC election. If election is combined then
setup_election_config generate the combined event(
for example 'TC & PTL Election') and it does not work
with those tools/scripts.
This fixes it and even for combined election it generates
the separate events. If we look at the election site, the
separate events are more clear for users.
Generated config looks like below:
Change-Id: I7d2e540dea9d89c832f6d9e3e9da743fe8d39295
---
release: 2023.2
election_type: combined
tag: mar-2023-elections
tc_seats: 4
timeframe:
name: Zed-2023.1
start: 2022-03-11T00:00
end: 2023-02-15T00:00
email_deadline: 2023-02-15T00:00
timeline:
- name: TC Nominations
start: 2023-02-01T23:45
end: 2023-02-15T23:45
- name: PTL Nominations
start: 2023-02-01T23:45
end: 2023-02-15T23:45
- name: TC Campaigning
start: 2023-02-15T23:45
end: 2023-02-22T23:45
- name: TC Election
start: 2023-02-22T23:45
end: 2023-03-08T23:45
- name: PTL Election
start: 2023-02-22T23:45
end: 2023-03-08T23:45
Change-Id: I5b1766d0fce9eb7ded000a7b582a8e4086314831
As per TC charter, nomination and voting period
has been changed from 1 week to 2 week. Updating
the setup_election_config.py script to select the
duration according to TC charter.
Also, updating the validate_tc_charter() to validate
the latest TC charter.
Below is output of this updated script:
Change-Id: I209db4d8a21af79047aee061b51802a7d2bac74b
---
release: 2023.2
election_type: combined
tag: mar-2023-elections
tc_seats: 4
timeframe:
name: Zed-2023.1
start: 2022-03-11T00:00
end: 2023-02-15T00:00
email_deadline: 2023-02-15T00:00
timeline:
- name: TC & PTL Nominations
start: 2023-02-01T23:45
end: 2023-02-15T23:45
- name: TC Campaigning
start: 2023-02-15T23:45
end: 2023-02-22T23:45
- name: TC & PTL Election
start: 2023-02-22T23:45
end: 2023-03-08T23:45
From Antelope (2023.1) onwards, primary identifier
of any release is release version instead of name[1],
we should use release versions in the election tooling
also.
This migrate the election tooling to use the release version
As release repo is not fully migrated to release version yet,
we still need to use the release name to fetch the data from
release repo.
Keeping relaese version as float so that we edit the
configuration file with release version a float not
with string even string is passed.
All the election tools/script/flow has been tested with it and
it is working now.
[1] https://governance.openstack.org/tc/reference/release-naming.html
Change-Id: Ia8a60a9514b1dca5ac97ed8099c34c6c6c7d24e2
The current tox setup results in an 'editable-wheel' install which,
while it works, generates unhelpful warnings. Switch to the 'editable'
type which is what you got under tox <= 4.
While we are reducing noise in the logs, correctly setup
openstack_elections.templates as a module. We need it as a module as
we rely on Jinja2 to be able to use the module loader to locate the
templates.
Change-Id: Icbdca2f72c0777c587d6f95b3fab1911be179f97
Currently the event name is limited to 'x-final', this doesn't
work for current releases. Update that to determine the correct
tag.
Change-Id: I14a2d71a0bc26c837ebe4dfebbcfc9b05f02b069
If the release name passed into the tool doesn't yet have a schedule,
which is actually the most common use case, we won't be able to
auto-detect a date. In that case let's bail somewhat nicely.
Change-Id: I4072e73c15d0299755fcce43f8b35798179719c3
Setting a variable to itself should be a no-op right? Frankly I have
no idea why I did this so remove it.
Change-Id: I9f9851c76455e5d559ba68921dfd29557a64b574
Tuesday was selected because it was early in the week and was "safe"
for APAC and US timezones. Releases actually happen on Wednesdays
so for something more like consistency lets do make elections also
happen on Wednesdays
Change-Id: If66602b12eb77b17904427149ab81ce7a21d9492
Adding the policy statement to combined election which was already
added in PTL and TC election voting kickoff templates
Change-Id: I10fbbab9d11512cb66a3e3eaaa3cfd4159e48513
Due to a new CIVS policy, to vote in a private CIVS pool,
participants must opt in to email communication.
This information is now added in the PTL and TC voting kickoff
emails.
Change-Id: Ib1dbd9a388bc8d88dc1ae95e0f92f953612f25b2
All strings are considered as unicode string from Python 3.
This patch drops the explicit unicode literal (u'...')
appearances from the unicode strings.
Change-Id: Ifd455c425249cefa0082607993c157e7b884f0e2
Current we need to pass 'date' as mandatory argument
in setup_election_config CLI and it is sometime confusion
on what date to pass.
This commit automatically select the end date of release if
date is not passed. This will help to generate the correct
election dates without worry about release date to pass.
Change-Id: I444885800b26ca84689d550f81bbe349eae3bd30
setup_election_config generate the election dates as per
the given release date but there is no validation of those
generated dates against TC charter.
This commit adds TC charter validation in this script which
will help to generate the correct dates macthing with what
TC charter says.
Change-Id: Ic79f4903e26785de4c6cb1f5908c5b5839975096
setup-election-config script is used to generate the
election dates. As we started doing the combined election
of PTL and TC, we need to add that type of election support
in this tool which will help to generate dates for any
type of election.
Below the is generated data will looks like:
release: yoga
election_type: combined
tag: oct-2021-elections
tc_seats: 4
timeframe:
name: Wallaby-Xena
start: 2020-09-25T00:00
end: 2021-08-24T00:00
email_deadline: 2021-08-24T00:00
timeline:
- name: TC & PTL Nominations
start: 2021-08-17T23:45
end: 2021-08-24T23:45
- name: TC Campaigning
start: 2021-08-24T23:45
end: 2021-08-31T23:45
- name: TC & PTL Election
start: 2021-08-31T23:45
end: 2021-09-07T23:45
Change-Id: Ib97f7ba794078ed78c9241dce7d40b3fc3519948
setup-election-config script is still using the old
dates for TC election
"The election is held no later than 6 weeks prior to each
OpenStack Summit (on or before 'S-6' week)"
and set the offset of 6 weeks of summit or release. As we do not
have summit in every cycle so we need to update it to take
reference from release dates.
Also TC charter is changed 2 year back about new recommended dates
for TC election, which is:
"The election is held no earlier than 6 weeks and no later
than 4 weeks prior to each cycle final release date (between 'R-6' and 'R-4'
week)"
- https://review.opendev.org/c/openstack/governance/+/699277/6/reference/charter.rst
This commit fix the script with the offset as 4 weeks from release date
so that generated dates will be as per the TC charter.
Change-Id: Id43b67add3ec405bd94c64a9d2d324247914031a
Our recent Gerrit upgrade has made the emails method of the REST API
require essentially administrator permissions, making it no longer
feasible to find secondary addresses for change owners. Secondary
addresses really only served minor uses in this library anyway,
helping identify redundant accounts (which new Gerrit is forcing us
to clean up) and allowing slightly looser association to foundation
profiles.
Drop our use of the emails method, relying instead on the preferred
address provided with the owner record. In rare cases where an
account lacks a preferred address, substitute the committer address
from the first revision of the change where we initially encounter
that user.
Change-Id: Iee58c38a728343776354260c8b2d3fad09633ffa
The close_election command treats TC elections as a single-team PTL
election, essentially. The leaderless list, however, is generated
from the full list of projects included in an election which, in a
parallel TC/PTL election will include more projects than just the
TC. Rather than heavily refactor the utility function where that
data is summarized, just delete the leaderless list from the
election results when reporting for the TC round in a parallel
TC/PTL election.
Change-Id: Ia8bb11addb9f70283b3e676d90e5e7b48494b8e1
Zuul