Update the URLs in various templates and generated content to
consistently use https:// instead of a mix of that and http://, and
while we're at it set the homepage for the Python package of this
repo to the election site rather than the OpenStack Foundation site.
Change-Id: I4fa53076ed9bcdf1545d9c4aa5e80dc5dad95210
The future_release expansion variable was being incorrectly set to
the name of the end release from the electorate contribution
timeframe. Its intended use however was redundant with the release
variable. Remove future_release entirely and just use release in
those templates.
Change-Id: I7df3592112d543b52b06c99bfbc05107bfde45f8
We currently have 2 CLI interfaces for generating change owners.
- owners ; and
- generate-rolls
And we maintain a shim to translate between calling arguments. In
I45d6c4d4fd454ae426883006db1e58dbd373bbdf (Support custom local
projects and legacy projects) we added --legacy and --projects to
owners. This change adds those options to the shim.
Change-Id: Ib38f26744e279f1271679ce1d075ad5a4e3ddb27
It turns out that structure of the TC and PTL elections is very similar
and therefore the template choices are basically the same. Remove the
overly complex sub-parser and always use the election_type from the YAML
configuration.
Also many of the fmt_args where shared, or harmless to share between
each election type. pull the similar items out and only adds the items
specific to each election type
Change-Id: Ifcc8a376e7d8d9a79ae7a9191cb2452f8cfbae43
While removing the duplication standardize on 'leaderless' as a term to
descibe projects without a defined leader (either a single candidate or
an election). Also standardize on 'election' rather than 'poll'
num_projects_without_candidates and projects_no_candidates are
functionally identical so use a new 'leaderless_count' count instead
projects_polling and list_of_elections are functionally identical so
pick the latter as it aligns with the new terminology
Change-Id: I7aa96e2acb3eca496dda55ded2faddbb09bdbbd1
This consumes (and modifies) render-statistics. Factoring this out will
be done at the end of the series
Change-Id: I878de8288f1ac047d844085f05261a6d3b1daac1
This slightly more complex than expected as we need to tie the template
to the config so we don't try to get_event() for TC events and fail.
This has been done in the least invasive way possible, we'll tidy things
up at the end of the series
Change-Id: Ib3c25072590507f347ee5ab3f3865eb4c991a34b
Add --legacy and --projects options to the owners CLI, which make it
possible to specify local alternatives for the legacy.yaml and
projects.yaml files. This enables easily running the tool for
unofficial/non-OpenStack elections which use the same Gerrit and
similar rules for determining their electorates other than the
actual repository lists.
Change-Id: I45d6c4d4fd454ae426883006db1e58dbd373bbdf
Now that we don't support Python 2.7 with this tooling, we can drop
the explicit encoding in invitee names. Without this change, they're
recorded as explicit byte sequences instead of normal UTF-8 strings.
Change-Id: I9e0220dbdb241ab6bd464fd5cdfcaf5f3e2a6399
When creating a new election we need to add a directory per project
(including the 'TC' as a pseudo project) we can't just create an empty
directory in git so we add a '.placeholder' file.
We have recently added a voting job that will run try to validate all
candidate files added in a review. This includes the placeholder file.
CLearly this file will not pass validation and cause the job to fail.
Adding .placeholder to the zuul irrelevant-files variable wont work, so
instead filter .placeholder from the interesting files.
Change-Id: Ibd2224a5479d4ab9afbac227bac38080359a98bf
Typically we have long enough post release to conduct an entire TC
election. However with Train (and possibly others) the gap between
release and summit is too short to allow for that. The current code
will set the eligibility criteria to allow for the release date meaning
that it's possibly for for electorate to change post-election which is a
bad thing.
Let's detect that and set the timeframe to a more logical value.
Before:
Setting TC Election
Summit is at: 2019-04-22
Latest possible completion is at: 2019-03-11
Moving back to Tuesday: 2019-03-05
TC Election from 2019-02-26T23:45 to 2019-03-05T23:45
TC Campaigning from 2019-02-19T23:45 to 2019-02-26T23:45
TC Nominations from 2019-02-12T23:45 to 2019-02-19T23:45
Set email_deadline to 2019-02-19T00:00
* Setting TC timeframe end to stein Release date 2019-04-10T00:00
Begining of Rocky Cycle @ 2018-02-09 00:00:00+00:00
* End of Stein cycle @ 2019-04-10 00:00:00+00:00
* Election timeframe: 425 days, 0:00:00s
* Looks like election timespan is outside of 'normal'
* Minimum: 334 days, 14:00:00
* Current: 425 days, 0:00:00
* Maximum: 395 days, 10:00:00
After:
Setting TC Election
Summit is at: 2019-04-22
Latest possible completion is at: 2019-03-11
Moving back to Tuesday: 2019-03-05
TC Election from 2019-02-26T23:45 to 2019-03-05T23:45
TC Campaigning from 2019-02-19T23:45 to 2019-02-26T23:45
TC Nominations from 2019-02-12T23:45 to 2019-02-19T23:45
Set email_deadline to 2019-02-19T00:00
* Setting TC timeframe end to email_deadline
Begining of Rocky Cycle @ 2018-02-09 00:00:00+00:00
* End of Stein cycle @ 2019-02-19 00:00:00+00:00
* Election timeframe: 375 days, 0:00:00s
Change-Id: I2ca38ea68cd179659a53a4bebe68215d91865e67
Now that the last tool that needed python2 has been checked/fixed lets
remove all the python2 infrastructure and make all library users exit if
run under python2
Change-Id: I20184300f0a6cb6d230428cafc49f1b917376380
When generating electorate rolls under python3 we get the following:
Traceback (most recent call last):
File ".tox/venv/bin/generate-rolls", line 10, in <module>
sys.exit(main())
File "/home/tony/projects/openstack/openstack/election/openstack_election/cmds/generate_rolls.py", line 84, in main
owners.main(options)
File "/home/tony/projects/openstack/openstack/election/openstack_election/owners.py", line 532, in main
normalized_project = normalize_project(project)
File "/home/tony/projects/openstack/openstack/election/openstack_election/owners.py", line 60, in normalize_project
return project.translate(maketrans(' -', '__')).lower()
TypeError: a bytes-like object is required, not 'str'
Remove the python2 compat code and just use str.maketrans() always.
Change-Id: I12e351886d3e431144eeeb3a0efbd94dd0552946
By default ci_check_all_candidate_files.py, does as it implies and
checks all candidates for the current election.
Add new operation modes for:
1. Checking all files for the current git commit '--HEAD'
2. Checking all files specified on the command line
We also add a voting job on the check pipeline only for validating
the current review. Local users are encouraged to use this as:
tox -e ci-checks-review ; or
tox -e ci-checks-review -- path/to/file
Change-Id: I0c82c59409bb58169840de42c02072aeae182b2b
Co-authored-by: Doug Hellmann <doug@doughellmann.com>
We have utils.find_candidate_files() which correctly detects the type of
election and returns the appropriate list of files. Lets use that
so limit the CI checks we do.
Change-Id: I36ccfa82137d0f05a031ab2a50dd4eb87a32094b
Currently we use glob.glob() to get a list of files to validate. We
make a simple choice to only use 'TC' for TC elections and '*' for PTL
elections. This mostly works when the TC election is after the PTL
election. Consider the following tree:
candidates/some_election/TC/candidate@one
candidates/some_election/TC/candidate@two
candidates/some_election/project_one/candidate@three
candidates/some_election/project_one/candidate@four
candidates/some_election/project_two/candidate@five
The current logic will check only candidate@one and candidate@two for a
TC election but all files for a PTL election if the PTL election happens
after the TC election.
So factor out the file system logic so we can correctly include/exclude
the TC based on the election type.
Change-Id: I493d3663afda9d5e849176b3e6a9d042e0af7f3e
For the most part the dates for an election can be known in advance and
the formula for working them out isn't too complex.
Add a tool that, given some simple args, can make an educated guess as
to when an election should be run.
Change-Id: Ied3b5e2d4494f325bda549f303e68151856008bf
In tc_nominations_kickoff() we need to refer to the most recent release
which we did correctly in Icf1274ebc957e8b74fa35c0f0c791ae22f079b16 but
when we merged all the fmt args in
I8b439c76fa1d14624c0119ab05b1561c6cf424c9 we didn't noticed that
'future_release' is used differently in tc_nominations_kickoff().
This last introduces a new 'last_release' key that differs from
end_release only in case :(
Change-Id: I02f1e6a9cfa1a6e327f6d463723ec67bf0f873e5
Instead of generating fmt_args specifically for each message combine all
the per-function instances in a global tc_fmt_args. This makes finding
duplicates easier.
Change-Id: I8b439c76fa1d14624c0119ab05b1561c6cf424c9
voting_{start_end} are aliases for election_{start,end} and
end_nomination{,s} are the same thing so simplify the args the print
function.
Change-Id: I63ed2d5d75725efa775d443362bf8677947caf06
Use the data in the config to supply the details for the
tc_nominations_kickoff email. Also switch the printing to use keywords
to make it clear what's going where.
Change-Id: Icf1274ebc957e8b74fa35c0f0c791ae22f079b16