| gmann | ianychoi[m]: changing DPL model is not allowed during election but a new repo or a new project application can come and we might accept the one right? adding new repo in the projects is fast and can be added by TC anytime it is proposed and reach two TC members vote. | 01:07 |
|---|---|---|
| gmann | ianychoi[m]: and giving we have made election nomination two weeks it will be a significant change to count the electorates before two weeks | 01:08 |
| gmann | I mean we can do that but waiting for election nomination end and releasing gov tag does not harm much right? considering we do that 1 week of TC Champaign time | 01:09 |
| gmann | we cannot freeze projects change for repo addition or a new project application but by pre-ponding the email_deadline at election nomination start date, we will be excluding those new repo/project contributors from electorate which IMO can be avoided eaisly with current process | 01:15 |
| ianychoi[m] | Thank you gmann. Yep, logically fair if we related tagging with rolling stuff for election. I was just wondering why tag number is using on this part - I think we can change to use "main" branch instead of a tag number for such rendering - https://governance.openstack.org/election/#project-team-leads-election | 02:25 |
| gmann | ianychoi[m]: yeah, using main branch at particular date and that can be the checkpoint to generate the electorate. this is good idea. | 16:48 |
| fungi | actually determining after the fact what commit that was can be tricky, since you need to check for the date that changes merged rather than when they were committed | 16:52 |
| fungi | this is why we used to tag the commit we used in the governance repository instead | 16:53 |
| fungi | in a pinch we put a specific commit id in the config rather than a tag name, and then asked to have that commit tagged after the fact | 16:54 |
| gmann | it can be simple, checkout latest governance master while generating the electorate. | 16:55 |
| fungi | traditionally we tagged or picked a commit toward the end of the nomination period since that way we'd also know the state of the governance repo which was used to validate ptl candidates | 16:55 |
| fungi | in order to avoid a different list of projects getting used to validate ptl candidates than was used to pick valid contributors for the electorate | 16:56 |
| gmann | i mean it can be done in other way if tag is becoming difficult process. honestly saying tag is more better way and does not require much effort. | 16:56 |
| gmann | as election official in past also or releasing tag does not take time or difficulty | 16:57 |
| fungi | yes, for some of those i proposed the tag to the releases repo and then got the tc chair to +1 it | 16:58 |
| gmann | yeah | 16:58 |
| fungi | and, if urgent, asked the release managers to expedite approval once that was done | 16:59 |
| gmann | yeah, release team is anyways up to merge them fast, just ping them | 17:00 |
| ianychoi[m] | Thank you - now I am inclining to leverage tag numbers for rolls. Fixing doc rendering would be another action item. | 17:08 |
| ianychoi[m] | Through 0.15.0 tag, there are total 309 electorates (fyi log - https://paste.opendev.org/show/bfgcXWeFAVSxuoc03Ey9/ ) | 17:10 |
| ianychoi[m] | (for TC) | 17:10 |
| opendevreview | Ian Y. Choi proposed openstack/election master: [WIP] Add template for CIVS opt-in https://review.opendev.org/c/openstack/election/+/893591 | 18:00 |
| opendevreview | Ian Y. Choi proposed openstack/election master: Add template for CIVS opt-in https://review.opendev.org/c/openstack/election/+/893591 | 18:11 |
| opendevreview | Ian Y. Choi proposed openstack/election master: Add template for CIVS opt-in https://review.opendev.org/c/openstack/election/+/893591 | 18:13 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!