| -opendevstatus- NOTICE: Recent POST_FAILURE job results with no logs were due to upload errors in one of our providers, which has been temporarily disabled now so rechecking those should be safe | 15:05 | |
| gouthamr | tc-members: o/ gentle reminder taht our weekly IRC meeting will be hosted here in ~45 minutes | 16:16 |
|---|---|---|
| gouthamr | #startmeeting tc | 17:00 |
| opendevmeet | Meeting started Tue Mar 24 17:00:43 2026 UTC and is due to finish in 60 minutes. The chair is gouthamr. Information about MeetBot at http://wiki.debian.org/MeetBot. | 17:00 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 17:00 |
| opendevmeet | The meeting name has been set to 'tc' | 17:00 |
| gouthamr | Welcome to the weekly meeting of the OpenStack Technical Committee. A reminder that this meeting is held under the OpenInfra Code of Conduct available at https://openinfra.dev/legal/code-of-conduct. | 17:00 |
| gouthamr | Today's meeting agenda can be found at https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 17:01 |
| gouthamr | #topic Roll Call | 17:01 |
| gouthamr | noted absence: dansmith, s p o t z | 17:01 |
| gouthamr | (dan mentioned he didn't mind the ping) | 17:01 |
| gouthamr | courtesy ping: frickler noonedeadpunk cardoe mnasiadka bauzas | 17:02 |
| gouthamr | ping check | 17:03 |
| cardoe | bleh. I'm always here 5 minutes before and then tab over to another IRC channel and forget to come back | 17:03 |
| noonedeadpunk | o/ | 17:03 |
| noonedeadpunk | ++ | 17:03 |
| gouthamr | ah, ty.. i was afraid i was typing into the ether when noone showed up at first :D | 17:04 |
| bauzas | doh, missed to ping | 17:04 |
| * gouthamr waits another minute | 17:05 | |
| bauzas | (and then I jumped into another chan) | 17:05 |
| gouthamr | no worries, are there any fires atm? | 17:05 |
| gouthamr | let's get started | 17:06 |
| gouthamr | #topic Last Week's AIs | 17:06 |
| mnasiadka | o/ | 17:06 |
| mnasiadka | cardoe: I did the same :) | 17:06 |
| cardoe | gouthamr: just code reviews | 17:06 |
| gouthamr | spotz took one to refresh the election liaison: https://review.opendev.org/c/openstack/election/+/964733 | 17:06 |
| gouthamr | think we're doing well with the masakari situation: https://review.opendev.org/c/openstack/governance/+/981213 | 17:07 |
| gouthamr | noonedeadpunk: you've an AI regarding deprecating vitrage and retiring venus | 17:08 |
| gouthamr | these two have been dropped from the gazpacho release: https://review.opendev.org/c/openstack/releases/+/980900 | 17:08 |
| gouthamr | besides masakari, venus and virtrage, we're done with the leaderless projects | 17:09 |
| noonedeadpunk | Will push patches in next hour or so.... I believe I have staged changes already... | 17:10 |
| gouthamr | ty noonedeadpunk; please do mail openstack-discuss when you have the patches | 17:10 |
| gouthamr | that's all the AIs i see, was anyone working on anything else? | 17:10 |
| gouthamr | #topic PTG | 17:11 |
| gouthamr | #link https://etherpad.opendev.org/p/apr2026-ptg-os-tc (TC PTG Etherpad) | 17:11 |
| gouthamr | ^ a gentle reminder to add any anticipated topics to the etherpad | 17:12 |
| fungi | i see you already have the user survey on there, that's one reminder i can check off my to do list. thanks! | 17:12 |
| gouthamr | ++ | 17:13 |
| gouthamr | if you think of anything you'd like to chat about, add it here and fill in the details later | 17:13 |
| gouthamr | cardoe: i wanted to connect the dots regarding skyline | 17:14 |
| cardoe | Sure thing | 17:15 |
| gouthamr | have the contributors that you were aware of downstream made any more progress with the project? | 17:15 |
| cardoe | They've been pushing patches slowly. | 17:15 |
| gouthamr | i asked wu_wenxiang a couple of places on expanding their core team | 17:16 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/978067/comments/f54cdeae_821f623c | 17:16 |
| gouthamr | this was their response ^ | 17:16 |
| gouthamr | so it's in as bad a state as it was about a year ago.. the three current maintainers are keeping up with reviews, and keeping the project governance going, but, they haven't seen any suitable candidates | 17:17 |
| cardoe | Yeah I would agree there. | 17:17 |
| cardoe | I know there's a few downstream forks. | 17:18 |
| cardoe | Which just doesn't help the overall effort. | 17:18 |
| cardoe | https://review.opendev.org/q/owner:sowmya.kamavaram@rackspace.com is probably the person with the most contributions recently. | 17:19 |
| gouthamr | ty, ack.. probably still building on reviewer credibility: https://review.opendev.org/q/reviewer:sowmya.kamavaram@rackspace.com | 17:20 |
| cardoe | Yep. Sowmya need to review more. | 17:20 |
| gouthamr | if you wouldn't mind sharing our latest/renewed feelers that we need help maintaining the project, this would be super helpful! | 17:21 |
| cardoe | Will do I'll poke folks. | 17:21 |
| gouthamr | ty cardoe | 17:21 |
| gouthamr | sorry, thought of this when planning the PTG.. if sowmya/others want to discuss skyline, or talk about any barriers to contributions in general at the PTG, i'd welcome it.. | 17:22 |
| gouthamr | anything else about $topic? | 17:22 |
| gouthamr | #topic PQC and the OpenStack TC | 17:24 |
| gouthamr | #link https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/OEVG4K7PTKL34CYZCL4KQIXOYRP7KJNV/ | 17:24 |
| gouthamr | mharley[m] was looking for a TC liaison to propose a pop up team around Post Quantum Cryptography | 17:24 |
| gouthamr | is there anyone interested? i don't know if they'll seek time and share any further details at the upcoming PTG... | 17:26 |
| gouthamr | but, if you're interested, mharley[m] can get in touch with you directly and add you on the Pop Up Team proposal that they were going to write. | 17:26 |
| fungi | there's also precedent that you don't have to be a tc member to be a tc liaison (i'm still the tc liaison for the image encryption pop-up team) | 17:26 |
| gouthamr | ah, good point! | 17:27 |
| fungi | "the TC is responsible for seeking a volunteer experienced sponsor to help the new popup team be successful and act as a liaison with the TC." | 17:28 |
| fungi | (doesn't say it has to be a tc member) | 17:28 |
| gouthamr | ++ you'd be a good two-way contact and push for awareness and governance changes here that'd help the pop up team | 17:28 |
| fungi | not me specifically, of course, in this particular case, but whoever volunteers | 17:29 |
| gouthamr | yes, should've phrased that differently | 17:29 |
| gouthamr | alright, if you're interested, please do respond on the ML or let mharley[m] know.. | 17:29 |
| gouthamr | #topic A check on gate health | 17:30 |
| gouthamr | any gate related news to share for this week? | 17:30 |
| fungi | the job failures related to fetching files off static sites in opendev should be gone since mid-last week | 17:30 |
| fungi | we ended up expanding the resources for hosting all of that, and turning off some mitigations that were getting overwhelmed by the recent request flood | 17:31 |
| mharley[m] | Hello, everyone. Thank you for raising the point, gouthamr. I was drafting the reply to send to list today, but the day was quite busy. | 17:31 |
| mharley[m] | I shall send a reply later on. I do think the pop up team is the best approach in the PQC case. | 17:31 |
| gouthamr | ty mharley[m] | 17:31 |
| mharley[m] | * Hello, everyone. Thank you for raising the point, gouthamr. I was drafting the reply to send to the list today, but my day was quite busy. | 17:31 |
| mharley[m] | I shall send a reply later on. I do think the pop up team is the best approach in the PQC case. | 17:31 |
| mharley[m] | YW | 17:32 |
| fungi | today we had a bout of post_failure jobs related to swift problems in one of our donor providers and have temporarily excluded them from the log upload pool | 17:32 |
| gouthamr | fungi: \o/ great news on the static site fixes | 17:32 |
| fungi | on the whole it seems like things have settled down a little | 17:32 |
| fungi | there were some concerns expressed late last week about grenade jobs not running for stable/2026.1 yet, not sure if that's resolved now but it was the usual timing for branching those pieces | 17:32 |
| clarkb | yes, I think they fast tracked the creation of branches for devsatck and grenade to resolve that | 17:33 |
| gouthamr | +1, i ran an override in the manila jobs.. but, it's supposed to be fixed in base | 17:33 |
| clarkb | both repos have a stable/2026.1 branch now | 17:34 |
| gouthamr | #link https://review.opendev.org/q/topic:%22qa-2026-1-release%22 | 17:34 |
| fungi | opendev sysadmins are trying to be mindful of the impending openstack release next week, and focusing on making things stable/avoiding making potentially risky changes at the moment | 17:34 |
| fungi | (not that we don't always try to keep things stable, but software upgrades and maintenance windows are semi-on-hold) | 17:34 |
| gouthamr | on April 1st, it'll be (╯°□°)╯︵ ┻━┻ | 17:34 |
| fungi | totes | 17:35 |
| gouthamr | ty for the updates | 17:35 |
| gouthamr | let's go to Open Discussion and discuss reviews/other things | 17:37 |
| gouthamr | #topic Open Discussion | 17:37 |
| gouthamr | we're doing well on the open reviews, a couple of things need attention | 17:37 |
| gouthamr | #link https://review.opendev.org/q/project:openstack/governance+status:open | 17:37 |
| gouthamr | noonedeadpunk: https://review.opendev.org/c/openstack/governance/+/974775 | 17:38 |
| gouthamr | don't know if you had any thoughts on frickler's review there | 17:38 |
| gouthamr | fwiw, these os-ansible repos were not really "un-retired" properly | 17:38 |
| * noonedeadpunk clean forgot about it | 17:38 | |
| gouthamr | i.e., the repos had no useful content after re-activating them | 17:38 |
| noonedeadpunk | no, nothing was done or pushed to repos since un-retirement attempt | 17:39 |
| noonedeadpunk | thus I wanted to kinda revert the patch and pretend it never happened :D | 17:39 |
| gouthamr | haha, git is like pepperidge farms | 17:40 |
| gouthamr | sorry, that meme may not be universal | 17:41 |
| gouthamr | https://review.opendev.org/c/openstack/governance/+/979815 need some reviews | 17:41 |
| gouthamr | the dependencies have to merge before it can merge, but please do see if you have any objections to raise | 17:42 |
| noonedeadpunk | but anyway - I can update the date, though the fact is that technically it was never alive after reviving... | 17:43 |
| gouthamr | yes, i don't think either approach is wrong | 17:43 |
| gouthamr | explain yourself in the commit message and folks should be able to find the reasoning | 17:43 |
| gouthamr | #link https://review.opendev.org/c/openstack/governance/+/981832 (Use Gerrit hashtags instead of topics for change classification) | 17:44 |
| gouthamr | ^ just wanted to provide some more context to this change: | 17:44 |
| gouthamr | we use "topic" today to classify changes so we can advance them through review | 17:44 |
| gouthamr | the automation is a script in the governance repo: | 17:45 |
| gouthamr | https://opendev.org/openstack/governance/src/branch/master/tools/check_review_status.py | 17:45 |
| gouthamr | i run it occasionally to see how things are before workflowing changes.. | 17:45 |
| gouthamr | i notice when things are submitted here though that folks like to customize their topic to relate changes on gerrit.. useful tool, same as hashtags.. except hashtags are so much better.. you can have many of them | 17:46 |
| gouthamr | so i feel we could change our approach to use hashtags so people can have whatever topic they want. | 17:47 |
| gouthamr | very minor thing, but it changes our process so i've asked for a wider consensus.. we've been using hashtags for a couple of years now | 17:47 |
| bauzas | this seems something to be educated tbh | 17:48 |
| gouthamr | yeah, in real cross project changes too, there's now a good deal of hashtag usage.. | 17:49 |
| gouthamr | alright, that's all i had for reviews today.. | 17:50 |
| gouthamr | i'd keep an eye on this repo: | 17:50 |
| gouthamr | #link https://review.opendev.org/q/project:openstack/openstack-manuals+status:open | 17:50 |
| gouthamr | with the release, we'll have some changes here that'll help to get merged in a timely manner | 17:51 |
| gouthamr | i see spotz[m], cardoe and frickler there very often, thanks for doing reviews there | 17:51 |
| fungi | we also got rid of the magic topic mangling in the last git-review release because gerrit upstream intends change topics for other purposes, and hashtags are what serve the purpose we used to abuse topics for (`git review --hashtags ...`) | 17:51 |
| gouthamr | oh | 17:52 |
| gouthamr | what was the git review behavior before? I see that it uses the local branch name to set the topic | 17:52 |
| bauzas | that's what I'm saying : should be something mentioned to the whole community, not only for our own usage | 17:52 |
| gouthamr | ++ on hashtags, super useful feature | 17:52 |
| fungi | https://docs.opendev.org/opendev/git-review/latest/releasenotes.html#relnotes-2-5-0 | 17:53 |
| fungi | #link https://docs.opendev.org/opendev/git-review/latest/releasenotes.html#relnotes-2-5-0 git-review 2.5.0 release notes | 17:53 |
| gouthamr | AH! | 17:53 |
| gouthamr | thank you, that was super annoying as a default feature.. i need to update git-review | 17:53 |
| gouthamr | i never knew about gitreview.notopic | 17:54 |
| gouthamr | but, now i don't need it :D | 17:54 |
| fungi | indeed | 17:54 |
| fungi | you skipped straight to nirvana | 17:54 |
| gouthamr | lol \o/ | 17:54 |
| gouthamr | alright, the last few mins to add anything else to our minutes today | 17:56 |
| gouthamr | alright, thanks everyone.. see you at this meeting next week | 17:59 |
| gouthamr | #endmeeting | 17:59 |
| opendevmeet | Meeting ended Tue Mar 24 17:59:49 2026 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 17:59 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2026/tc.2026-03-24-17.00.html | 17:59 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2026/tc.2026-03-24-17.00.txt | 17:59 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2026/tc.2026-03-24-17.00.log.html | 17:59 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/governance master: Retire Venus Project https://review.opendev.org/c/openstack/governance/+/981959 | 18:09 |
| opendevreview | Dmitriy Rabotyagov proposed openstack/openstack-manuals master: Retire Venus Project https://review.opendev.org/c/openstack/openstack-manuals/+/981966 | 18:20 |
| sean-k-mooney | gouthamr: it depend on yoru workflow. i personaly hate that git review dose not use the current branch as the as the topic anymore | 18:23 |
| fungi | i think what change topics mean got reinterpreted by gerrit upstream when they implemented their "submit whole topic" feature to imply changes that were tightly-coupled and had to merge together rather than just being a bit of freeform metadata | 18:24 |
| sean-k-mooney | right so i really dont want to use hashtags for anythig | 18:25 |
| fungi | with the idea being if you needed freeform metadata that's why there were hashtags (even though they didn't come along until many years after topics had existed) | 18:25 |
| sean-k-mooney | topic is how we track thigns across brnahces | 18:25 |
| sean-k-mooney | and repos | 18:26 |
| clarkb | right but you can use hashtags for that purpose | 18:26 |
| clarkb | which is useful since gerrit decided tpoics means something else | 18:26 |
| sean-k-mooney | you coudl but that a masive braking change | 18:26 |
| fungi | for at least some (popular in our circles) use cases yes | 18:27 |
| gouthamr | in our behavior and some of our tooling? not really "breaking" anything else, no? | 18:27 |
| sean-k-mooney | no not really anything else then all our mucel memory and our contibnutre workflow and tooling :) | 18:28 |
| sean-k-mooney | using hastags is less harmful then the native work in progress feature i guess | 18:28 |
| sean-k-mooney | im very glad we dont use that | 18:28 |
| fungi | it does seem like gerrit didn't take into account the degree to which topics were being used in different ways by users when they decided to grow additional functionality depending directly on one specific use for them, but from a git-review perspective we're just trying to avoid deviating from upstream expectations and sowing confusion about gerrit features | 18:29 |
| sean-k-mooney | as cores dont have the ablity to move thigng out of "work in progress" state | 18:29 |
| fungi | sean-k-mooney: they could if the acl granted it to them | 18:29 |
| sean-k-mooney | we coudl do tha tbut i would rather block that feature entirly via acl | 18:30 |
| sean-k-mooney | so that cont9ibutors cant create a parallel flow to workflow -w | 18:30 |
| fungi | how are the cores taking workflow -1 votes out of wip? pushing entirely new revisions of changes and waiting for them to get tested all over again? | 18:30 |
| sean-k-mooney | which is what we document to use | 18:30 |
| sean-k-mooney | fungi: that or if it doesnt need any chagne jus tupdating the lable | 18:31 |
| sean-k-mooney | but i cant change teh work in progress state by pusshing a new revsion | 18:31 |
| fungi | keep in mind that workflow -1 was a hack we implemented because they didn't accept the patches we had originally proposed upstream for a wip toggle feature (which we were running in a fork for years) | 18:31 |
| sean-k-mooney | at least the last time i tried it didnt seam tobe possibel | 18:31 |
| fungi | 17:15 <opendevreview> Dmitriy Rabotyagov proposed openstack/project-config master: Allow OpenStack-Ansible Cores to change WIP state https://review.opendev.org/c/openstack/project-config/+/981925 | 18:32 |
| clarkb | correct the native wip state is persistent. But you can have an acl that allows you to unset it. I wonder if it is possible to make native wip not sticky. But it isn't implemented as a label so none of the label copy condition stuff applies | 18:32 |
| fungi | if we standardized that in project acls the way we standardize workflow -1, it would be possible | 18:33 |
| gouthamr | https://review.opendev.org/c/openstack/project-config/+/959904 | 18:33 |
| fungi | would be possible for core review teams to unset it i mean | 18:33 |
| sean-k-mooney | it would but it will break third party cis that filter on this in zuul | 18:33 |
| gouthamr | i want everyone to be able to unset it | 18:33 |
| sean-k-mooney | and it breaks dashbaord too | 18:33 |
| fungi | i mean, if the third-party ci systems are running zuul, it supports the wip toggle inherently. it's not like it magically did so, ci systems have to evolve over time to support new features | 18:34 |
| noonedeadpunk | I still think it's not great to allow everyone to unset it | 18:34 |
| noonedeadpunk | As a contributor I am setting WIP label to ensure that things are not considered ready for production | 18:35 |
| sean-k-mooney | fungi: i mean that assume we adopt the use of the new features | 18:35 |
| clarkb | yes we haven't made that change globally in gerrit as it seems like somethign that would be a project specific expectation for behavior | 18:35 |
| clarkb | but projects can opt into allowing cores to do it for example | 18:35 |
| noonedeadpunk | and I totally don't want a random user to unset it | 18:35 |
| noonedeadpunk | which can then super easily slip Cores attention | 18:35 |
| sean-k-mooney | and if we do that we need to udpate our refences to the curent way of doint thing to reflect that | 18:35 |
| noonedeadpunk | during the review | 18:35 |
| sean-k-mooney | clarkb: i woudl treat it the same as the workflow lable | 18:35 |
| noonedeadpunk | yes, I think cores is fine to opt in and that is at least would be acknowledged by the core team | 18:36 |
| sean-k-mooney | which i think is teh owner of the patch or the core team | 18:36 |
| noonedeadpunk | ++ | 18:36 |
| sean-k-mooney | the problem with that is it require change to every repo to list the relenvet core team | 18:37 |
| sean-k-mooney | well every acl for each repo | 18:37 |
| * gouthamr is in a meeting, will read scrollback | 18:37 | |
| fungi | sean-k-mooney: which they already do to grant them other permissions, including workflow -1..+1 | 18:39 |
| sean-k-mooney | fungi: yep it just woudl be less work to entirly disable the wip togle | 18:40 |
| sean-k-mooney | which was my suggestion disabel the feature by acl entril | 18:40 |
| sean-k-mooney | *entirly | 18:40 |
| sean-k-mooney | i would do the same for the ablity to push a patch as private too for what its worth since we do not use that even for security bugs | 18:41 |
| clarkb | I'm not sure we can do that | 18:41 |
| * clarkb checks | 18:41 | |
| fungi | it would be less work to disable lots of things. the wip toggle was something we were imperfectly working around the lack of for many years after we abandoned our own fork, but people have gotten so accustomed to the temporary hack that it's like a form of stockholm syndrome | 18:41 |
| gmaan | honestly saying I am not sure what is actual gain of 'not using "topic"'. projects/people can use hashtag if they like but we should not discourage/ban the use of "Topic" which has been working in all situation | 18:42 |
| sean-k-mooney | the only poiblle gain might be not having to fix it when cherry-picking | 18:42 |
| gmaan | and how that is easy than adding hashtag man ually :) | 18:42 |
| sean-k-mooney | because of the new behvior every time i cherry pick a patch to stabel via the ui | 18:42 |
| sean-k-mooney | i have to manually fix the otpic | 18:43 |
| fungi | it adds confusion for users of other gerrit installations, where the submit-whole-topic function is used to make all changes with the same topic merge at the same moment | 18:43 |
| clarkb | gmaan: the reason to not use topic is to avoid confusion for gerrit users. Topic means something else in almost every other gerrit server that exists | 18:43 |
| gmaan | yeah, so that is fine, its a 2 sec work :P | 18:43 |
| clarkb | topic for everyone else means "these changes will merge together when submitted" | 18:43 |
| gmaan | but in openstack, we knows for what we use it right so that should be ok | 18:43 |
| sean-k-mooney | well yes an no you have to expcilty do that you can merge them without mergin all in topic | 18:44 |
| sean-k-mooney | we had this and useed it in our downstream gerrit | 18:44 |
| clarkb | up until the point where Gerrit decides to enforce that behavior more strictly. Currently submitwholetopic is optional (we have it disabled) | 18:44 |
| sean-k-mooney | i.e. we woudl merge all the backport of a serise at once | 18:44 |
| gmaan | I mean I am not saying do not use hashtag, use it if you need more filter or so but that should be additional things to do not replacement | 18:44 |
| sean-k-mooney | clarkb: well that woudl be a major braking change to not allow you to disable it | 18:44 |
| clarkb | encouraging people to use the tools more consistently with upstream expectations avoids problems if/when we upgrade and the expectation is more than a suggestion. It also makes it easier for people to work with different installations | 18:45 |
| sean-k-mooney | we use topci for thing like the openapi or eventlet removal series | 18:45 |
| gmaan | and for almost every features tracking across projects/repo | 18:45 |
| fungi | i agree that it would have been nicer if gerrit upstream had introduced an entirely new field to be used for indicating change interdependency and left topics as just an informational string semi-redundant with hashtags instead of overloading them with new context. but they didn't | 18:45 |
| gmaan | for example if any nova feature need tempest change then having same topic is useful for me to see what feature/service side change happening | 18:46 |
| clarkb | the only work in progress config I can see is the ability to set all changes to wip by default on push | 18:46 |
| clarkb | I don't see a way to turn it off | 18:46 |
| sean-k-mooney | fungi: is the plan to automate the conversion of every topic ot a hastag | 18:46 |
| clarkb | sean-k-mooney: no I think we're hoping that if people start using them it will naturally transition over time | 18:46 |
| sean-k-mooney | fungi: becuase if we dont that is actully a big problem if thye ever make submit topic the defualt | 18:46 |
| fungi | i think it's one possible solution if that ever happens, sure | 18:47 |
| sean-k-mooney | clarkb: but we will have mergable patches for decades with topic set | 18:47 |
| clarkb | topics don't live forever. If the next new topic is a new hashtag instead that is one less. Then eventually there will be no active topics used in the way we use them today | 18:47 |
| sean-k-mooney | clarkb: topics do live for ever in my usage of them | 18:47 |
| clarkb | those changes are not active anymore | 18:47 |
| sean-k-mooney | sure the may not have open or activly developed patches | 18:47 |
| clarkb | they would require rebasing at the very least in the vast majority of cases | 18:47 |
| fungi | also if a change sites for decades before it merges, updating the topic is probably the least significant thing that's going to need to be done to it | 18:47 |
| fungi | s/sites/sits/ | 18:48 |
| sean-k-mooney | fungi: im more concerned about the "submit whole topic becomeing default becvhior" | 18:48 |
| sean-k-mooney | what happens if zuul submit a ptch aon repo a that is on the same topic as one on repo b | 18:48 |
| fungi | if it does happen in a future gerrit version, then yes that's something we'll have to plan to address during the upgrade process | 18:49 |
| clarkb | sean-k-mooney: currently if you enable submit whole topic zuul will treat the entire set as a unit and they all have to pass together to merge together | 18:49 |
| sean-k-mooney | that would be a security issue based on our current usage model | 18:49 |
| clarkb | sean-k-mooney: so we're largely safe there I think | 18:49 |
| fungi | almost every major gerrit upgrade comes with some behavior change or other that we end up addressing during the upgrade | 18:49 |
| clarkb | nothing can merge in the zuul model unless you +2 everything and also approve everything and everything passes tests when combined into a singular unit | 18:49 |
| sean-k-mooney | clarkb: but we dont use topic just for work in a sincle repo | 18:49 |
| clarkb | sean-k-mooney: yes so what would happen is things will fail to merge because they wno't all work together and be approved together | 18:50 |
| clarkb | I think the likely scenario is that you can't merge anything with those topics set | 18:50 |
| clarkb | rather than accidentally merging the wrong thing | 18:50 |
| sean-k-mooney | are you sure about that if there is no depens on between them | 18:50 |
| clarkb | yes zuul is submit whole topic aware | 18:50 |
| clarkb | because literlaly every other gerrit uses gerrit this way | 18:50 |
| sean-k-mooney | ack | 18:51 |
| sean-k-mooney | i think if we updated to a verion with this enabeld by default we shoudl consider removing the topic form open changes adn adding a hashtag but i guess we can assess that if it ever happens | 18:52 |
| clarkb | also gerrit's gerrit made the transition so it is possible. I don't think we need to worry about that now. There is no timeline or plan for making this default as far as I know. But they have been known to do things like that. For example I was personally warned that we shouldn't depend on case sensitive gerrit usernames forever | 18:52 |
| fungi | right, it can be scripted and done through the rest api as one of our upgrade steps if we decide it's needed | 18:52 |
| clarkb | whcih is about a million times bigger of an issue than topics. Particularly if we just stop using topics by default and naturally transition over time | 18:52 |
| sean-k-mooney | will git review now use hashtags by default based on the branch name? | 18:53 |
| sean-k-mooney | or will it just not use either and you have to opt in | 18:53 |
| clarkb | no, I think you have to set the flag | 18:53 |
| clarkb | yes that | 18:53 |
| fungi | no, but you can set hashtags on push with a command-line option just like you can still set topics with a command-line option | 18:53 |
| sean-k-mooney | ack it annoys men that we need to pass -t now but i guess i can adtap of implement it diffently in my grt tool | 18:55 |
| sean-k-mooney | althogh the grt tool is ment ot be compatibel with git-review so i shoudl follow its convetion i guess | 18:56 |
| clarkb | for the case sensitivity of usernames issue the first step is fixing our notedb database so that we can edit it via git pushes to the running service rather than editing git repos when gerrit is off. Then we would need to scan for all cases of collisions. Then we would need to do a similar thing to the current notedb cleanup and decide which of those accounts gets disabled and | 18:57 |
| clarkb | has its username deleted. | 18:57 |
| clarkb | A far far far more painful process than simply avoided topics by default | 18:57 |
| sean-k-mooney | are they not case sensitive today? | 18:58 |
| sean-k-mooney | they should eb right because they map to ssh usernames | 18:59 |
| clarkb | they are case sensitive in our installation through a specific flag to force them to be. Gerrit did case sensitive by default for a long time then switched to insensitive by default | 18:59 |
| sean-k-mooney | that seam like an incorrect defualt | 18:59 |
| fungi | basically a transition we haven't had time to follow yet | 18:59 |
| clarkb | I was told in paris by the gerrit folks that they think maintaining both behaviors forever is not likely to happen and eventually you will need to be case insensitive. I agree the default is bad | 18:59 |
| clarkb | auth.userNameCaseInsensitive = false | 19:00 |
| clarkb | that is the config setting we set | 19:00 |
| sean-k-mooney | do they prevenet registration of usernames that differ only by case | 19:00 |
| fungi | we're still finishing up the transition from before gerrit stopped allowing multiple accounts to have the same e-mail address | 19:00 |
| sean-k-mooney | because if not that is a problem | 19:00 |
| clarkb | sean-k-mooney: no not with that flag set I don't think | 19:01 |
| fungi | (finally down to a handful of accounts with conflicting addresses which we should be able to delete soon) | 19:01 |
| clarkb | and yes I would agree the handling of this is bad | 19:01 |
| clarkb | but thats kind of my point. They make these changes we don't have much choice but to follow along and do our best. | 19:01 |
| clarkb | Topics are basically a non issue in comparison | 19:01 |
| sean-k-mooney | i dont really have the energy to push back upstream and sugget they revers course | 19:02 |
| sean-k-mooney | but if they were to do this frequently it woudl make me question the sutiablity of gerrit as a review tool long term | 19:02 |
| sean-k-mooney | fortunally everything else is many orders of mangniture worse | 19:03 |
| clarkb | I don't think it is frequent. But they do make decisions that don't always necessarily work the best for us | 19:03 |
| sean-k-mooney | and that argurable are insecure | 19:03 |
| clarkb | and they haven't forced it on us yet. I was just warned that people weren't sure maintaining both behaviors forever was likely | 19:03 |
| clarkb | I think its secure as long as you are consistent about applying the rule | 19:03 |
| clarkb | you can't have a conflict when that value is flipped | 19:04 |
| sean-k-mooney | well when i ssh to the gerrit servier it sueign the user name to idenfy which public key to use | 19:04 |
| sean-k-mooney | so yes as long as there is validaton to prevent you fliping the flag | 19:05 |
| sean-k-mooney | when there are existing conflict it woudl be ok | 19:05 |
| sean-k-mooney | but otherwise its not great | 19:05 |
| fungi | when they made it so that accounts couldn't have conflicting addresses, they basically just broke the ability to update those accounts until an admin resolves the conflict | 19:06 |
| sean-k-mooney | i think i had an issue related to that on the rdo gerrit | 19:07 |
| sean-k-mooney | i use to use email and password and clicked the google login once by mistatek | 19:07 |
| sean-k-mooney | that lead to 2 acount with the same emial and i coudl not log in with either | 19:07 |
| fungi | yeah, it was not the smoothest transition, and as i said we're still working through it many years later | 19:08 |
| sean-k-mooney | so is https://review.opendev.org/c/openstack/governance/+/981832 going to aldo invole updating the exsitng goals to use hastags and fixing all the project specirfic docs | 19:09 |
| sean-k-mooney | basiclaly so that the comunity is aware of this change in paractice | 19:10 |
| gmaan | yeah, that is my concern on that change. if TC want to use or any project then it is fine as per their preference but I am not sure why it should be forced on all projects | 19:15 |
| clarkb | I don't think anyone is forcing anything | 19:16 |
| clarkb | I'm suggesting that if you use hashtags you'll get better functionality and you'll avoid potential problems down the road if submitwholetopic becomes less optional | 19:16 |
| gmaan | I agree on that suggestion, my 'forced' comment was for somewhere it was mentioned that it should be done in community level. TC, or any specific project want to use it then it is all fine but changing for goal tracking which need update for existing goal are unnecessary work. | 19:23 |
| gmaan | instead we can amend to suggest use of hashtag but should not remove the use of topic | 19:23 |
| * gouthamr is back, and woah | 19:24 | |
| gouthamr | hmm, okay, i can reword that suggesting that hashtags are preferred, but topic can be used if that's the goal champion's preference | 19:27 |
| gouthamr | ? | 19:27 |
| gouthamr | would that help, gmaan? | 19:27 |
| gouthamr | i don't know if you guys made the point already that we disable topic updates after a change has merged | 19:28 |
| sean-k-mooney | ya that a pain point | 19:28 |
| gmaan | I will not say which one is preferred instead just list two options and champion can choose | 19:28 |
| gouthamr | so, right now, if someone had a typo or a autogenerated topic for whatever reason, it lives, forever :/ | 19:29 |
| sean-k-mooney | i used to fix them if they were not set when backporting | 19:29 |
| sean-k-mooney | gouthamr: i dont actully object to the tc descing to adotp them formally in goals going forward | 19:29 |
| gouthamr | ack, sean-k-mooney: you don't want us to change the behavior for completed/ongoing work? | 19:30 |
| sean-k-mooney | gouthamr: the only real pain point i have had with topic in the past were, not auto seting them from the branch, not keeping it the saem when i backport and not being ablt to fix the topic after a patch was merged | 19:30 |
| gouthamr | i hate that too (╯°□°)╯ | 19:31 |
| sean-k-mooney | gouthamr: we coudl but if we did it shoudl really be automated | 19:31 |
| sean-k-mooney | what i dont really want to have to do is ahve some thign on topic and others using hashtags | 19:31 |
| gouthamr | sean-k-mooney: or through the UI.. i've been bulk-updating hashtags on things by doing a select-all, add-hashtag (or remove) | 19:32 |
| sean-k-mooney | gouthamr: with that said the only thim i have been annoy by topic of lat was when someone chagne the topic i was usign without asking | 19:32 |
| gouthamr | ah, yes.. that sucks.. i've annoyed people submitting changes to the governance repo because we had this automation based on topics | 19:33 |
| gouthamr | "hey, i've set this topic on twenty other changes so people can gain context, but why does it have to be "formal-vote" over here :/ | 19:33 |
| sean-k-mooney | gouthamr: well we have project convetion too | 19:34 |
| gouthamr | yes, i noticed the hashtag on reviews milestones? in nova | 19:34 |
| sean-k-mooney | i.e. bugs should be on the topic bug/<number> and feature shoudl be on bp/<blue print name> | 19:34 |
| sean-k-mooney | gouthamr: we dont formallyuse them for nova | 19:35 |
| sean-k-mooney | not for any documented usecase | 19:35 |
| sean-k-mooney | but folks might be using them informally | 19:35 |
| gouthamr | ack, probably people creating their own review dashboards | 19:35 |
| sean-k-mooney | yep hashtags are free form | 19:35 |
| sean-k-mooney | but also not documented in our contibutor docs because they are not part of any formal process in theproject today | 19:36 |
| gouthamr | true | 19:36 |
| clarkb | topics are free form too. But you can only have one | 19:36 |
| sean-k-mooney | yes and we docuemtn what it shoudl be set too | 19:36 |
| gouthamr | yeah, we've just created some recognizable ones and patterns "bug/<id>", "bp/<id>" and documented this behavior.. i'm not suggesting we change this right away, maybe we should slowly.. this stuff is "relatively new" in our contribution timeline | 19:38 |
| sean-k-mooney | if we docuement the change and new patterens and comunicate it like the DSO change im fine with it even if i prefer the old way | 19:39 |
| sean-k-mooney | but this si a similar fundemetal change as adotping the use of signed off by on every commit | 19:39 |
| fungi | not quite as ubiquitous at least, you can't push changes into gerrit at all on official opensdtack deliverables without signed-off-by | 19:40 |
| gouthamr | true, not as legally binding so we can do it as slowly as our brains/processes need to adopt.. | 19:40 |
| gouthamr | adapt* | 19:41 |
| sean-k-mooney | we need to update https://docs.opendev.org/opendev/infra-manual/latest/developers.html#starting-a-change at a minium | 19:43 |
| sean-k-mooney | and stop refeing to them as topic branches in general i guess | 19:43 |
| gouthamr | yes | 19:43 |
| sean-k-mooney | well https://docs.opendev.org/opendev/infra-manual/latest/developers.html#git-branch-names to be more preciese | 19:43 |
| fungi | i'm happy to review proposed updates to infra-manual, i agree a lot of it is stale | 19:45 |
| sean-k-mooney | well i would not codier this to be stale | 19:46 |
| sean-k-mooney | that is what i expect all contubotr to nova/placment/watcher/cybrog to follow | 19:46 |
| sean-k-mooney | alwasy use a topic, and ideally it shoudl be bp/BLUEPRINT or bug/BUG-NUMBER | 19:47 |
| sean-k-mooney | so we can track the related spec and or repoducer for a bug fix | 19:48 |
| sean-k-mooney | in the case where the chagne is a chore or other ativity that does not fit into those catagories the branch name/topci cna be anyting meaningful | 19:49 |
| sean-k-mooney | fungi: for what it sworth reading it now the only thing that is possibel stale to me is the fact it implies that the topci will automaticly match the brahcn and that -t is optional | 19:52 |
| gouthamr | ack, i don't expect you to change this.. but, as PTL if you think you would start adopting hashtags, i'd be interested in how your experience goes.. I don't want to kick up anything that'll break your productivity! will bring this up for wider discussion with other project maintainers too... | 19:52 |
| sean-k-mooney | well the tooling we had built aroudn this downstream is dead with the death of our downstream gerrit | 19:53 |
| sean-k-mooney | the tooling i was plannign to build myself was goign to use topic as one of the inputs but i have not worked on that much so hashtag vs topic is not much of a change i just never planned ot use hastags personal | 19:54 |
| sean-k-mooney | eitehr filed is fine btu the imporat part ot me is having a single way to group related changes across repos and branches | 19:55 |
| sean-k-mooney | since i need to review backprot across brnaches often and having them on a single topic was importnat to that | 19:56 |
| sean-k-mooney | as was the nameing convetion or discoverablity | 19:56 |
| fungi | the main reason i prefer hashtags over topics for that sort of tracking, upstream gerrit decisions aside, is that if you wanted to track changes with multiple pieces of metadata you had to implement some bespoke serialization to set them all in the change topic | 20:01 |
| sean-k-mooney | can we add hastag on merged changes | 20:02 |
| sean-k-mooney | not being able to fix the topic on a merged change has ocationlly made enforcing the convetion or findign the change later harder | 20:03 |
| fungi | the webui seems to indicate it will let me | 20:03 |
| sean-k-mooney | i guess taht an improvemnt if nothign else | 20:04 |
| fungi | i added "vmt" as a hashtag on https://review.opendev.org/c/openstack/ossa/+/981207 | 20:04 |
| fungi | even though it merged yesterday | 20:05 |
| fungi | so seems to work | 20:05 |
| fungi | and then i deleted it again | 20:05 |
| sean-k-mooney | look like everyoen can do that but that proble fine | 20:05 |
| fungi | the comment record shows both events too | 20:05 |
| sean-k-mooney | 99% of peopel dont even knwo those files exist | 20:05 |
| sean-k-mooney | ya so at least there is an audit trail of sorts | 20:06 |
| sean-k-mooney | part of the reason we do this is because we cant use "close-bug", "Related-Bug" and "Partial-Bug" or simialr commit messsage data for this | 20:07 |
| sean-k-mooney | well not without just usign the generic search | 20:08 |
| sean-k-mooney | techinaly https://review.opendev.org/q/%232140631 works | 20:08 |
| sean-k-mooney | it works less well when it comes to features | 20:09 |
| gouthamr | yes! being able to change metadata on a closed change is a win.. | 20:24 |
| frickler | sorry I was away unexpectedly. I think I've responded to all reviews that were mentioned now | 21:19 |
| gouthamr | thanks frickler | 21:19 |
Generated by irclog2html.py 4.1.0 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!