| opendevreview | Jay Faulkner proposed openstack/governance master: TC resolution: migrate to sqlalchemy2 https://review.opendev.org/c/openstack/governance/+/887083 | 13:01 |
|---|---|---|
| JayF | tc-members: I will not be at the meeting, but I have found time to revise my governance resolution. Please consider re-reviewing it. Thank you! | 13:02 |
| slaweq | Hi. I'm in the PTO this week and will also not be at the meeting | 13:11 |
| dansmith | fungi: are you going to be on the tc call today? | 13:34 |
| JayF | Can I strongly suggest we keep discussion about the EM stuff in gerrit changes? | 13:37 |
| JayF | It's significantly refreshing to talk about real concrete proposals instead of talking about ideas; it feels more action-oriented and it ensures those discussions will be preserved | 13:37 |
| JayF | I guess; saying no is easier than saying yes, and seeing concrete opposing proposals might be a more effective way to communicate what your alternatives are :) | 13:40 |
| dansmith | seems to me like we're still in the brainstorming ideas phase | 13:41 |
| fungi | dansmith: i can try to join the call, but have been experiencing trouble with my headset. also the calls are mostly useless for me because i feel like i can never get a word in edgewise. gerrit/ml/irc is much easier to have those sorts of discussions | 13:42 |
| dansmith | fungi: what about when I say "fungi, tell me why this is hard" ? :) | 13:43 |
| fungi | sure, so long as i don't have to try to interrupt seven other people ;) | 13:44 |
| JayF | fungi: fwiw, you aren't the only one, we do a bad job of stepping on each other in the zoom calls... it makes it very difficult for me to understand at times | 13:57 |
| JayF | (part of why I'm not too upset that the zoom monthly meeting is the one I'm missing, frankly) | 13:57 |
| dansmith | I really don't understand why people prefer in-person communication or IRC but don't like zoom. For me, it's way harder to hear people in a echoy room with tons of people typing where everyone is sitting in various places and with differing volumes | 13:59 |
| dansmith | the volume-leveling of a video conference makes it much easier for me to understand everyone in a conversation | 13:59 |
| JayF | dansmith: I prefer IRC, ML, and Gerrit to all forms of communication, including in-person. | 13:59 |
| JayF | dansmith: I sometimes read lips and that's very very difficult on zoom | 14:00 |
| dansmith | and I also feel like more side conversations happen in person, which completely destroys my ability to follow any one conversation | 14:00 |
| JayF | so it's just basically a phone conference in terms of being able to follow and understand | 14:00 |
| JayF | dansmith: If everyone hated IRL communication as much as we do; I'd be in my home country and TZ right now ;) | 14:01 |
| fungi | i can go back and re-read what people said in irc even if multiple people said different things at the same moment. i also am not all that keen on in-person discussions for these sorts of topics, if you were in the forum room for this particular topic you likely understand why | 14:01 |
| JayF | I blocked out the memory of that forum session -.- | 14:02 |
| dansmith | well, not all of us are able to type and read accurately and quickly either, so I think it's probably reasonable that we cater to a number of communication mechanisms for the same reason you both don't like video calls | 14:03 |
| fungi | agreed. though i'm dyslexic and a horribly slow reader and typist, for the record. i'm just even worse at trying to have a simultaneous voice conversation (on a call or in person) with a similar number of participants | 14:04 |
| spotz[m] | The advantage of written is if you don't understand you can re-read and if talked over the messages are just out of order but still there | 14:05 |
| JayF | Yeah, I've 100% realized I've misread/miswritten something but I never get to have that second look if I'm speaking | 14:05 |
| JayF | (or listening) | 14:06 |
| fungi | i don't object to having voice discussions in addition to written ones, just want to make it clear why you don't hear much from me in the voice discussions and disproportionately more in the written ones | 14:06 |
| fungi | people who prefer talking can come up with some ideas, people who prefer writing can come up with some other ideas, and people who are skilled at both can try to help bridge the gap and find consensus | 14:07 |
| TheJulia | fungi: for the record, I would have never guessed that since you do seem to "hold your own" in high bandwidth discussions. That being said, if you ever need me to slow/redirect discussions your engaged with which I'm moderating, please don't hesitate to prod me. | 14:45 |
| fungi | TheJulia: much appreciated, but yes i've spent many decades finding effective optimizations and coping strategies, so i manage just fine for the most part though it does help increase my empathy for others who have more trouble than i do | 14:49 |
| TheJulia | Talking does at least convey emotion/passion/pain, and allows a conversation to head in other areas based upon tone/intonation. Humans, at least in my experience, tend to over compensate with words, or hold that hold emotion as context which then creates barriers as the shared context is not entirely known or the same. There is a time and place for each tool, but I also would strongly discourage bifurcating written word | 14:50 |
| TheJulia | discussion. | 14:50 |
| TheJulia | fungi: understood. I'm in a similar boat. Plus my hearing is getting worse. :( | 14:51 |
| fungi | oof | 14:51 |
| TheJulia | \o/ for lip reading! | 14:51 |
| TheJulia | Partially why I'm so quick to try and halt parallel discussions at the board meetings. The other discussion spikes the noise in the signal to noise ratio. | 14:55 |
| TheJulia | Halt is the wrong word, redirect. | 14:56 |
| fungi | makes sense | 14:57 |
| fungi | and also much appreciated | 14:58 |
| knikolla | I strongly believe that the concrete proposal that I put forward was much better at gathering "brainstorming feedback and ideas" than an unstructured discussion may have had. It was successful at highlighting key opinions that prior discussions either between the TC, or in ML with the community have struggled to elicit. It was the primary reasons why almost everything is bullet point and written in the verbose way that it is. | 15:10 |
| knikolla | I believe Gerrit is a better venue and allows people who wouldn't otherwise respond to a mailing list thread the ability to comment on individual lines, whether those be related to the motivation, goal, or implementation. | 15:11 |
| knikolla | Especially as it promotes various rounds of iteration and a feedback loop that is otherwise missing in IRC or ML discussions. | 15:12 |
| TheJulia | knikolla: Based upon my perception, I agree. I also believe etherpad is a good tool in a moment, but often information/data dies there as it is not memorialized nor really able to be discovered and easily destroyed. I think Gerrit is the right place given this is a continuation of a long running discussion. | 15:13 |
| dansmith | brainstorming in an etherpad and converting proposals (or something headed towards consensus) into a gerrit review is a good workflow, IMHO | 15:21 |
| dansmith | just commenting on a concrete proposal that's very far off the mark can be hard, in that it's hard to propose a large change in a small comment box | 15:22 |
| dansmith | etherpad makes it easier to co-locate several things near each other for easier referencing, but it of course needs to turn into something concrete | 15:23 |
| dansmith | and gerrit is definitely the place to fine-tune that and gather _documented_ consensus | 15:23 |
| fungi | alternatively, if someone feels that an existing proposal is far off the mark, making a separate competing proposal can work too (as long as people can be diligent about keeping comments focused on the specific proposal they're posted to) | 15:33 |
| dansmith | for sure, if there's a concrete alternative ready to be formalized | 15:34 |
| TheJulia | fungi: +1 | 15:35 |
| knikolla | The concrete alternative that I heard from the feedback on my proposal is keeping branches open indefinitely in a separate namespace. | 15:36 |
| dansmith | indefinitely isn't a critical aspect of that, but I also don't understand why we wouldn't, but the namespace thing is what needs discussion about feasibility | 15:37 |
| dansmith | that's why I think it's not worth a competing proposal document yet | 15:37 |
| dansmith | I'll be glad to do that work if we think it's doable and likely to be acceptable by more than just myself | 15:37 |
| TheJulia | We shouldn't be making proposals only if they are likely to be acceptable. We should be making proposals and working to reach consensus... which means the goal really is for nobody to be happy because a mutual compromise has been reached. | 15:39 |
| knikolla | Then I propose to keep the discussion in the meeting today focused on two key items: 1) can we move branches to a separate namespace for EM from a technical perspective, and if yes, 2) how long can we reasonably keep them open there? If it's not indefinitely, what is the criteria for defining when to close it. | 15:39 |
| dansmith | TheJulia: I'm sure you can sympathize with a desire not to write up a formal document for a proposal that has already been mentioned before and concerns raised, right? | 15:41 |
| dansmith | it seems like we might be swirling back towards that as the solution that solves more of the problems, | 15:41 |
| dansmith | but since it was previously kinda NAKed (without much discussion) I think it's worth a brainstorming-level discussion before we go to the work of trying to formalize something like that | 15:41 |
| TheJulia | dansmith: I can absolutely sympathize, but if it helps move overall discussion to conclusion through a concrete proposal, then it may save time. | 15:42 |
| fungi | as for specifics, the "build it and they will come" technical debt we're maintaining just in hopes someone will show up to use it is the fundamental failure we have for the current extended maintenance approach, so i have concerns about any proposal that involves similarly building or maintaining something just in case someone might show up to use it. better to build that thing when there | 15:44 |
| fungi | is someone who is actually going to use it (and can help shape and implement it) | 15:44 |
| dansmith | that ^ :) | 15:45 |
| TheJulia | shifting gears, I do agree, but I've also found we resist when trying to do the needful to help address issues/items. There is a happy balance, someplace. (I surely hope!) | 15:46 |
| TheJulia | And that resistance is more process/policy versus a team trying to be helpful. Granted, limited, but there is debt there as well. Is it worth it... is a value proposition. | 15:47 |
| fungi | for example, the ideas previously floated about creating new copies of all our git repositories we'll never be able to delete (gerrit doesn't support deleting projects), that we can't easily cherry-pick changes between, et cetera. if someone needs a new repository it can be created, but it's not clear to me that a fork of cinder marked as "unsupported" with old branches in it is going to | 15:48 |
| fungi | be any better for the cinder team than "unsupported" old branches in the original repo | 15:48 |
| TheJulia | Personally, I'm on the fence overall. I can totally see the operator POV, and I can see the developer POV. Honestly, conflicted is a easy word to use to describe how I feel. :) | 15:48 |
| TheJulia | That sounds painful :) | 15:49 |
| dansmith | fungi: right, that's the sort of thing I want to discuss before we start writing up things, | 15:49 |
| dansmith | although I will say I think the separate repo makes a huge difference :) | 15:50 |
| dansmith | I incorrectly referenced archive.ubuntu.org, but what I meant was this: | 15:51 |
| TheJulia | What time is the meeting today, I want to join if I don't have a conflict | 15:51 |
| dansmith | http://old-releases.ubuntu.com/releases/ | 15:51 |
| fungi | it definitely takes up lots of extra space on our gerrit server to have additional copies of those repos, and from a technical perspective there's nothing having multiple forks in gerrit will let you do that you can't already make happen with separate branches in one repo | 15:51 |
| TheJulia | even just to listen | 15:51 |
| fungi | TheJulia: 18:00 utc | 15:51 |
| dansmith | very clearly a distinction of "don't use this crap, it's not supported, but if you're stuck and you need packages, you can point your apt here and get the latest thing we had" | 15:51 |
| dansmith | forever | 15:51 |
| TheJulia | \o/ four hours of meetings! | 15:51 |
| TheJulia | actually, more like 5 :( | 15:52 |
| fungi | ubuntu's old releases site isn't git repositories, they just moved some files into different directories. "moving" branches to a different git repository is a far different sort of thing implementation wise even if you can explain it as sort of looking similar | 15:52 |
| knikolla | TheJulia: there's a zoom link here as this week it's on zoom https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee | 15:52 |
| TheJulia | knikolla: muchas gracias | 15:53 |
| dansmith | fungi: sure I understand, but from the consumer point of view, it's the same thing | 15:53 |
| dansmith | (IMHO) | 15:53 |
| knikolla | con mucho gusto | 15:53 |
| fungi | then from a consumer point of view we can do something to provide a consumer interface that presents things we way we want to present them without compromising the backend implementation | 15:54 |
| gmann | i agree on doing brainstrom first before jumping to any specific proposal on gerrit. use this etherpad to put out the ideas https://etherpad.opendev.org/p/openstack-exteneded-maintenance | 15:54 |
| dansmith | fungi: but then I as a nova developer, who subscribes to every change in nova/ will need to manually filter out all that other stuff | 15:55 |
| dansmith | if we're trying to reduce the load on the project teams, branches aren't much separation for the tooling that the projects use | 15:55 |
| fungi | by "other stuff" you mean all those em patches that nobody's been proposing, or something else? | 15:56 |
| dansmith | fungi: nobody's proposing? | 15:56 |
| TheJulia | gmann: but proposals have been made. Shifting discussion into an etherpad doesn't do those proposals justice unless it is to create an entirely separate proposal. | 15:56 |
| dansmith | there's a dearth of people stepping up to *maintain* and *review*, but those EM branches get plenty of backports | 15:56 |
| fungi | that was the argument i heard for dropping the em branches is that it's ended up being the developer teams on the projects doing all the backports to em branches, so no different than just calling those branches "maintained" | 15:57 |
| dansmith | TheJulia: we're literally discussing another proposal that was made in that etherpad | 15:57 |
| gmann | TheJulia: no, it never meant to be that way. in previous TC meeting we wanted to brainstrom first on ML/call etc and then in gerrit | 15:57 |
| TheJulia | then don't try to funnel all discussion to it. | 15:57 |
| TheJulia | explciitly say "we're working on another proposal/" | 15:57 |
| gmann | TheJulia: did you check etherpad, it has many other proposal also | 15:57 |
| dansmith | TheJulia: you might've missed it, but the original call was for some brainstorming, as I recall | 15:58 |
| gmann | that is what i mentioned in email last week | 15:58 |
| gmann | dansmith: yes | 15:58 |
| TheJulia | I glanced at it, and saw the discussion here, at which point I chimed in. | 15:58 |
| dansmith | i.e. to continue discussion of potential options since nothing super lear was materializing | 15:58 |
| gmann | I sent in email also about brainstorming more ideas in etherpad or even new idea if anyone from community has | 15:58 |
| fungi | anyway, gerrit is not a fork-oriented review platform, so i'm concerned about proposals that create extra work for someone who isn't the proposer | 15:59 |
| dansmith | and for those of us that couldn't participate in this discussion in person to continue the brainstorming, | 15:59 |
| dansmith | instead of just assuming the brainstorming had happened in an exclusive location and roll forward from that without further ideas | 16:00 |
| dansmith | me being one of those people of course | 16:00 |
| gmann | if we are close/almost agree to the proposal in advance/brainstrom then it make sense to me to push on gerrit and see how it goes | 16:00 |
| dansmith | fungi: ack, I understand, which is why I've been arguing *against* pushing this as a concrete proposal until we can have a handle on the technical challenges | 16:00 |
| dansmith | I specifically said that in my review on the current proposal, when I was asked if just flipping to "new namespace" would make me drop my objection | 16:01 |
| gmann | yes, that is what i raise concern last week before it was pushed in gerrit as a concrete proposal. | 16:01 |
| fungi | dansmith: to be clear, there was pretty much zero brainstorming that happened in the forum session. it was the usual airing of grievances and people explaining why having branches kept open would be good for them but not actually willing to commit to addressing the problems around making it a reality | 16:01 |
| gmann | *raised | 16:01 |
| TheJulia | fungi: there was background context that was expressed which did come off as grievances | 16:02 |
| gmann | i think we planned the next step after forum sessions which was continue discussion/ideas on ML, meeting and then see what proposal solving the issues and more closure to agreement | 16:02 |
| knikolla | gmann: Thank you for starting the etherpad. One point of feedback is that your etherpad narrowly poses the problem as "people expect us to be doing the maintenance under EM, how can we fix these communication issues", rather than as "Extended maintenance doesn't currently work as it currently exists. How can we provide value moving forward in a way that minimizes overhead." | 16:02 |
| dansmith | fungi: well even better to continue (or start) the brainstorming phase then :) | 16:03 |
| gmann | knikolla: sure, feel free to add problems you think it has in etherpad and we can brainstrom on "what are the problem we want to solve" | 16:03 |
| dansmith | knikolla: the beauty of an etherpad is that it's not owned by gmann so you can change it up | 16:04 |
| gmann | knikolla: I feel EM still value for users/operators but we need to change the communication and maintenance scope | 16:04 |
| dansmith | knikolla: I can do that to your gerrit proposal too, but it's not quite as nice of a thing to do :) | 16:04 |
| fungi | yes, we're at the starting brainstorming phase in my opinion. i don't think that having people propose straw man approaches is a bad way to brainstorm, regardless of whether it's in gerrit for easier reference | 16:04 |
| TheJulia | I would encourage decomposing the problem further, to be entirely honest. There is a capability and a perception issue which is intertwined that the TC previously struggled with quite a bit back in the 2018 timeframe | 16:04 |
| dansmith | fungi: nope, totally fine, but I also don't think we should be shutting down the etherpad of brainstorming ideas either :) | 16:04 |
| fungi | agreed | 16:05 |
| dansmith | TheJulia: yeah, there have been multiple suggestions in the review on the current approach around breaking the problem into pieces | 16:05 |
| gmann | so first step, let's agree to the problem we want to solve. that is what we are lacking here. | 16:05 |
| dansmith | I'm sure you're on top of that, I'm just saying | 16:05 |
| fungi | there are multiple problems different people want solved | 16:05 |
| TheJulia | fungi: ++ | 16:06 |
| fungi | and those problems are entangled (some justifiably, some on accident) | 16:06 |
| gmann | fungi: yeah that is what I am saying let's list and agree to those. if those are different problem we might have multiple soltuion | 16:06 |
| dansmith | entangled may be an understatement :) | 16:06 |
| gmann | anyways, feel free to add problems you want to solve and the possible ideas to solve them and we can brainstrom those | 16:07 |
| knikolla | Agree on the necessity of reaching consensus for the problems that we're trying to solve. | 16:07 |
| TheJulia | we don't necessarilly need to agree on a solution in the same agreement | 16:20 |
| TheJulia | fwiw | 16:20 |
| TheJulia | "recognize the problem" is the first step | 16:20 |
| * TheJulia goes back to meeting | 16:20 | |
| fungi | also we shouldn't assume there will be "a" (as in only one) solution, since there are multiple problems we may need to implement multiple solutions to address those different problems | 16:21 |
| TheJulia | ++ | 16:21 |
| TheJulia | Or potentially agree not to. | 16:23 |
| fungi | what's the url for the conference room? | 18:02 |
| spotz[m] | I'm looking for it | 18:02 |
| fungi | never mind, found it | 18:02 |
| spotz[m] | share:) | 18:02 |
| spotz[m] | NM | 18:03 |
| knikolla | #startmeeting tc | 18:03 |
| opendevmeet | Meeting started Tue Jul 11 18:03:15 2023 UTC and is due to finish in 60 minutes. The chair is knikolla. Information about MeetBot at http://wiki.debian.org/MeetBot. | 18:03 |
| opendevmeet | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 18:03 |
| opendevmeet | The meeting name has been set to 'tc' | 18:03 |
| noonedeadpunk | o/ | 18:03 |
| knikolla | #link https://us06web.zoom.us/j/87108541765?pwd=emlXVXg4QUxrUTlLNDZ2TTllWUM3Zz09#success | 18:03 |
| knikolla | Hi all, this is the week where the meeting happens on Zoom | 18:03 |
| knikolla | #topic Roll call | 18:03 |
| gmann | o/ | 18:04 |
| spotz[m] | o/ | 18:04 |
| dansmith | o/ | 18:04 |
| knikolla | o/ | 18:04 |
| knikolla | #topic Extended Maintenance | 18:05 |
| knikolla | #link https://etherpad.opendev.org/p/openstack-exteneded-maintenance | 18:05 |
| rosmaita | o/ | 18:06 |
| fungi | fwiw, adding groups to a gerrit acl is fairly straightforward. it can be done on a per-repo/acl basis or inherited by multiple repos/acls from a centralized parent acl | 18:22 |
| fungi | i still wouldn't want to go to the trouble of setting that up unless there are people who want to be added | 18:22 |
| fungi | also these are all basically things we already tried to encode in uc policy from the beginning (separate maintainers, removing ci jobs, et cetera), i guess we just failed to say that we really meant it? | 18:24 |
| fungi | for clarity, branches don't really get "renamed" they get created and deleted | 18:32 |
| fungi | we would branch unsupported/rocky from stable/rocky and then delete the stable/rocky head | 18:33 |
| fungi | also existing changes for stable/rocky would need to be abandoned (and then recreated if desired) | 18:34 |
| fungi | having the flexibility to adjust our processes based on changes in legislation is good, but i don't think we can base decisions on anything which hasn't become law | 18:39 |
| dansmith | yeah that's okay | 18:39 |
| fungi | effort is better spent on helping lobby for reasonable legislation | 18:39 |
| fungi | there's no reason we can't tag the last commit on stable/train as train-eol and then branch unsupported/train from the train-eol tag once someone decides they need to port a patch to that branch (it's still past the end of its life) | 18:44 |
| fungi | i appreciated closing on a jonathan swift reference | 19:04 |
| knikolla | #endmeeting | 19:05 |
| opendevmeet | Meeting ended Tue Jul 11 19:05:35 2023 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 19:05 |
| opendevmeet | Minutes: https://meetings.opendev.org/meetings/tc/2023/tc.2023-07-11-18.03.html | 19:05 |
| opendevmeet | Minutes (text): https://meetings.opendev.org/meetings/tc/2023/tc.2023-07-11-18.03.txt | 19:05 |
| opendevmeet | Log: https://meetings.opendev.org/meetings/tc/2023/tc.2023-07-11-18.03.log.html | 19:05 |
| knikolla | I noticed that RC-1 is not sticky in the governance repo patches, does anyone have a quick pointer to where that is defined in Gerrit config so we can switch it to be sticky? | 19:09 |
| gmann | knikolla: did not get, what exactly you mean but definition is here https://github.com/openstack/project-config/blob/39d0b03ce6cbc0f4ee188b339322bd0b893e028e/gerrit/acls/openstack/governance.config#L28 | 19:13 |
| knikolla | And for reference, as I failed to start recording on the meeting (apologies for that), the agreement at the end of the call was that I'll update the proposal to 1) rename extended maintenance to something else, like legacy or unsupported 2) mention development of branches being moved to a new prefix, instead of stable/train, either legacy/train or unsupported/train 3) clarify that +2/+A for these branches is going to be a separate Gerrit | 19:14 |
| knikolla | group, example nova-legacy-maint. Which may or may not be same as core or stable groups. 4) remove wording that says that the project team is responsible | 19:14 |
| knikolla | dansmith: did I forget something? | 19:14 |
| knikolla | gmann: you had a concern that new patchsets to a governance patch removed your RC-1, right? or did I misunderstand? | 19:15 |
| fungi | you mean a roll-call -1 vote is not persisting across new revisions of the change? | 19:16 |
| JayF | knikolla: a request, idk if this came up in the zoom, but can we only create the unsupported/ branches on demand? | 19:16 |
| dansmith | knikolla: that's the bulk of the obvious agreement I think | 19:16 |
| gmann | knikolla: no I mean if changing existing one mixup the things with old and this proposal things. but I am ok if you want to change in existing commit and we can see how it looks like | 19:16 |
| dansmith | gmann: I think knikolla is talking about the vote-wiping on the other change about sqla | 19:17 |
| gmann | knikolla: dansmith oh on sqla one? | 19:17 |
| JayF | Yeah, you had a comment that seemed to be unhappy that it dropped the RC-1 on revision | 19:17 |
| gmann | knikolla: dansmith 'legacy' convey meaning of 'unsupported' right? if not then may be we can name 'unsupported-legacy' | 19:17 |
| knikolla | ah, I may have misunderstood a comment from gmann on that patch as I see no vote wiping. | 19:18 |
| knikolla | Nevermind :) | 19:18 |
| JayF | I would prefer it be 100% clear it's not supported, unsupported does that better than any other possible method imo | 19:18 |
| JayF | legacy can be a positive thing in some contexts | 19:18 |
| knikolla | ++ on unsupported. | 19:18 |
| gmann | knikolla: yeah, it is update to change to voting wiping was valid action of gerrit | 19:18 |
| JayF | like I could see a corp calling their LTS product "legacy" | 19:18 |
| gmann | we are discussing two things and I myself got mixed up :) | 19:19 |
| gmann | knikolla: JayF dansmith on EM: yeah I feel we should choose name carefully this time and can be part of resolution | 19:19 |
| dansmith | I think unsupported/train should be short enough to be unoffensive to most, yet completely clear to anyone that it is... unsupported :) | 19:20 |
| JayF | Is the idea that all branches will get unsupported/ or will we only create them on request? and was there any talk of CI (I assume whoever picked it up would just nuke any changes they want?) | 19:20 |
| dansmith | if we were apple, we'd call it vintage/train and then people would collect them and make youtube videos about it | 19:20 |
| gmann | dansmith: branch prefix seems ok to me but gerrit group name 'nova-unsupported-core' seems odd, maybe 'nova-unsupported-branch-core' | 19:21 |
| gmann | nova-unsupported-train-core | 19:21 |
| dansmith | JayF: I think we're probably expecting automatic unsupported/ initially, and then renewal or some timeout after that, but we didn't come to any agreement there yet, nor for CI | 19:21 |
| JayF | dansmith: yeah, as an old computer collector I'm over here like "nooo, legacy sounds like something awesome I'd collect" ;) | 19:21 |
| knikolla | JayF: we sort of agreed on opt-in for unsupported/, but we didn't quite agree on what to do with the branches regarding when and how to EOL. | 19:21 |
| JayF | Yeah, the only piece I don't love about this is that unless you're using curated URLs/limiting review views by branch | 19:22 |
| fungi | i think that still needs to be decided, but the transition would look like 1. tag last stable/foo branch point release, 2. abandon any open changes on stable/foo, 3. create unsupported/foo branch from last foo point release, 4. delete stable/foo branch | 19:22 |
| JayF | unsupported/* patches will show up in review queue | 19:22 |
| dansmith | knikolla: one other thing we kinda mentioned that I'd appreciate you including is "a checklist of things we do when that happens, like rename, and delete the periodic jobs" but we don't necessarily need to actually enumerate those things in that doc, just that we should have a checklist | 19:22 |
| JayF | I'm asking if, using fungi's diagram, we can have a 2.5 that says 'human requests unsupported brnach be created' | 19:22 |
| knikolla | dansmith: ++ | 19:22 |
| dansmith | JayF: yeah me too, which is why I'd prefer another namespace but I think fungi will kill us all if we decide that, so.. compromise | 19:22 |
| gmann | fungi: yeah, that sounds the way | 19:22 |
| dansmith | fungi: ++ | 19:23 |
| fungi | JayF: in theory you could swap 3 and 4 around and then have a request step between them | 19:23 |
| JayF | yeah, that's sorta what I was asking | 19:23 |
| fungi | however that means devstack and similar integration testing needs three transitions (branch->tag->branch) instead of two (branch->branch) | 19:23 |
| gmann | for CI, I will say let's keep existing policy same as it is written | 19:23 |
| JayF | IDK if that's be more load for infra, or if people wouldn't love the added friction | 19:23 |
| fungi | i don't think it's extra work for infra since the release team already has all the permissions to do that delegated in acls | 19:24 |
| JayF | I should've s/infra/shared teams/ | 19:24 |
| fungi | yes. it may be more work for the release managers, or whoever else that activity gets delegated to | 19:24 |
| fungi | keep in mind that the people jumping up and down (ages ago but also recently) about being "broken" because we deleted a branch are going to experience that regardless of whether or not we create a new branch, since it won't be a seamless transition no matter how we go about it | 19:25 |
| JayF | fungi: I see that as more of a side effect of the previous EM branches having such a long lifetime that people drew incorrect assumptions from that | 19:26 |
| fungi | perhaps | 19:26 |
| JayF | (fwiw I am punting any love I had for the 'create on demand' idea if that is more work for shared teams) | 19:26 |
| JayF | fungi: at least with the proposal as summarized; those users would have to go stable/ -> unsupported/ after 18 months, it'd be a clear signal to them they are crossing an insecure barrier | 19:27 |
| fungi | what i like about create on demand is that we don't create things on the assumption they'll be of use to someone, and then end up with them hanging around even though nobody ever actually uses them | 19:27 |
| dansmith | yeah I sympathize with them wanting the branch name to never change, but recognize that there's a reason | 19:27 |
| JayF | so I sorta see that branch move as a feature? we were talking about it being hard to communicate to users if something was supported; having to type the string "unsupported/" really hammers it home lol | 19:28 |
| dansmith | like when you have to change your apt sources.list to point at old-releases | 19:28 |
| gmann | and it is benefit to long term and transition overahead of one time | 19:28 |
| dansmith | this ^ is the signal that you're in trouble :) | 19:28 |
| JayF | dansmith: which I think has value in a similar manner :) sometimes you have to have a little friction to make people listen | 19:28 |
| dansmith | yeah, I hate friction, but it's useful I know | 19:28 |
| JayF | I don't want to make it easy for people to do dangerous things; like running outdated software. (I have applied this to arguments around defaults in cleaning in Ironic, too -- make people make the choice to be insecure) | 19:29 |
| knikolla | So we still need to iron out 1) creation process (opt-in vs manual), 2) sunsetting process (when do we delete unsupported branches) 3) what testing will they have. | 19:29 |
| dansmith | I want it to be easy, but not invisible :) | 19:29 |
| fungi | we might be able to make a generic checkout fallback workflow for integration testing if we switch the order of eol tagging so that it's 1. tag stable/foo branch as eol-foo, 2. abandon open changes and delete stable/foo branch, 3. create unsupported/foo branch when someone asks for it | 19:30 |
| knikolla | But I'm really glad we all seem to be in consensus with regards to unsupported/*. | 19:30 |
| gmann | for 3) I will say keep same policy of no complete testing requirement which also means anyone can maintain any level of testing | 19:30 |
| fungi | basically when testing for stable/foo or unsupported/foo changes, first check if the dependency has a stable/foo branch, then check if it has an unsupported/foo branch, then checkout the foo-eol tag if there is neither | 19:31 |
| JayF | knikolla: I like that it more clearly reflects the reality. I'm worried creating branches up front will be mostly-performative; but that's not a large concern for me since people will clearly know they are doing something scary :) | 19:31 |
| gmann | 1) opt-in vs manual did not we agree on manual ? | 19:32 |
| knikolla | gmann: I'm sorry, I meant opt-in vs automatic. | 19:32 |
| gmann | or my mind is already in sleep mode | 19:32 |
| fungi | knikolla: just for you, devil's advocate... the term "unsupported" could be vague since we technically disclaim support for all our software. "unmaintained" could be clearer? | 19:33 |
| JayF | this is a shallow feeling, but unmaintained is a hard word to spell if you have to type it a lot | 19:33 |
| fungi | having an "unsupported" branch reopens the "what do we mean by support?" discussion, since it implies there is a supported branch | 19:33 |
| gmann | knikolla: yeah I was in impressions that automatic transition after branch pass the 'maiontained' state | 19:33 |
| knikolla | fungi: I like the paradox in having a nova-unmaintained-main in Gerrit. | 19:33 |
| knikolla | maint* | 19:33 |
| fungi | heh | 19:34 |
| JayF | dont-use-me-please-upgrade/antelope has a nice ring to it | 19:34 |
| knikolla | My initial suggestion once was vendor-sandbox/ | 19:34 |
| JayF | we call our unofficial ironic unsupported driver repo 'ironic-staging-drivers' | 19:34 |
| fungi | go-away-we-dont-want-any/train | 19:34 |
| JayF | not the best name but I think we steered away from vendor because they weren't all vendors | 19:35 |
| gmann | stable/archive-train | 19:35 |
| JayF | 💩/train | 19:35 |
| dansmith | yeah, don't use vendor | 19:35 |
| dansmith | and don't use anything with "stable" in the name, unless prefixed with "un" :) | 19:35 |
| knikolla | sandbox though sends a signal of absolutely no testing, all goes. | 19:35 |
| * JayF == dansmith | 19:35 | |
| JayF | I really like unsupported or (lesser) unmaintained | 19:35 |
| JayF | something that clearly has strong negative connotations | 19:35 |
| JayF | sandbox just doesn't sound like what this is at all | 19:35 |
| dansmith | same, unmaintained feels harder to say and type to me | 19:36 |
| fungi | if-it-breaks-you-get-to-keep-the-pieces/train | 19:36 |
| knikolla | i'm fine with unsupported, since we call the stage before it as supported. | 19:36 |
| gmann | +1 | 19:36 |
| knikolla | or do we not? | 19:36 |
| fungi | we do not | 19:36 |
| dansmith | fungi: stop it or I'm going to suggest fungis-cell-number/train :) | 19:36 |
| gmann | heh | 19:36 |
| fungi | knikolla: https://releases.openstack.org/ | 19:36 |
| JayF | just sell the naming rights | 19:36 |
| knikolla | ah, it's maintained. | 19:36 |
| JayF | haveacoke/train | 19:36 |
| dansmith | heh | 19:37 |
| gmann | yeah right 'Maintained' is the term we use | 19:37 |
| fungi | knikolla: hence why i suggested "unmaintained" but i agree that's harder to type | 19:37 |
| JayF | dead/train? | 19:37 |
| JayF | dead is probably too strong | 19:37 |
| knikolla | fungi: the problem is we already have a meaning for unmaintained == EOL. | 19:37 |
| dansmith | it's also not dead | 19:37 |
| knikolla | as the next phase after EM currently. | 19:37 |
| gmann | but it is clear to understand difference between our another terminology 'maintained' | 19:37 |
| dansmith | which is confusing, since it's next unmaintained, but actually EOL | 19:38 |
| JayF | Is there value in a world with unsupported/* branches, especially if they are opt-in-to-create, in having EOL? | 19:38 |
| JayF | because if not ... eol/train has a great ring to it | 19:38 |
| JayF | but reusing that term is probably a nogo | 19:38 |
| fungi | i wouldn't consider eol/train as a branch name to be off the table | 19:40 |
| fungi | it's also easy to type | 19:40 |
| JayF | honestly it would have a nice symmetry | 19:41 |
| JayF | you go master->stable/x->eol/x->x-eol tag | 19:41 |
| dansmith | that seems very confusing to me | 19:41 |
| dansmith | I'd much prefer maintained->unmaintained->eol | 19:41 |
| JayF | you konw what's interesting | 19:41 |
| JayF | we have to make it automatic | 19:41 |
| gmann | but branch is not *EOL* yet so eol/train is confusing | 19:41 |
| JayF | or we have to be able to zombie a branch | 19:41 |
| dansmith | gmann: right | 19:41 |
| JayF | we either have to be willing to create a net-new unmaintained/ branch out of a -eol tag | 19:42 |
| JayF | or create them automatically | 19:42 |
| JayF | that's a little gross | 19:42 |
| fungi | stable/train -> eom/train -> train-eol | 19:42 |
| JayF | I guess it depends on what we'd mean by opt-in? Like project-level opt-in (but that seems counter to the goal)... any-human-who-wants-it opt-in would have to have a timebox | 19:42 |
| gmann | 'unmaintained' is easy to understand the state of branch consider our other term we use to support is 'maintained' | 19:42 |
| JayF | yeah, I think that's right | 19:43 |
| JayF | and hopefully I won't be typing it a lot | 19:43 |
| fungi | maybe making it hard to type is a bonus ;) | 19:43 |
| JayF | I will say, we might wanna ask someone marketing-oriented from the foundation for naming ideas | 19:43 |
| JayF | they might have ideas we wouldn't think of | 19:44 |
| fungi | attractive-nuisance/train | 19:44 |
| JayF | I just dare anyone to say unmaintained/ussuri 10 times fast | 19:45 |
| knikolla | we could sell the naming rights, like a stadium. | 19:45 |
| knikolla | win win | 19:45 |
| JayF | knikolla: you're just gunning for the massopencloud/train, I see it ;) | 19:46 |
| fungi | sam-raimi/xena | 19:46 |
| knikolla | ugh, yeah, cause our github org is CCI-MOC which I hate typing. | 19:46 |
| JayF | post-branch-show-presented-by-casper-matress/train | 19:47 |
| knikolla | I like how everything in open source eventually turns into a naming brainstorm | 19:49 |
| JayF | knikolla: made the observation today that both computing and childbearing both are rife with naming and off-by-one errors (oh no, twins?!) | 19:49 |
| JayF | knikolla: while discussing what folks had named their kids :D | 19:50 |
| gmann | "naming brainstorm in open source == headache" which I already started having :) | 19:50 |
| JayF | I'm mostly just making jokes at this point, I think unmaintained has my vote of all the things presented | 19:51 |
| gmann | remembering the release naming days | 19:51 |
| knikolla | it's good to unwind and have some fun every once in a while :) | 19:51 |
| gmann | I am just saying. its good name suggestions though | 19:52 |
| knikolla | oh oh oh, i got it. you have to play a game of wordle to find out the branch prefix. | 19:52 |
| fungi | i had sworn off participating in bikeshedding discussions, but i've clearly fallen off the wagon | 19:52 |
| knikolla | it changes every day. | 19:52 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!