| gmann | tc-members: time to vote on the belmiro proposal for adding number in release name https://review.opendev.org/c/openstack/governance/+/829563 | 01:09 |
|---|---|---|
| opendevreview | Merged openstack/governance master: Appoint Wenxiang as Skyline PTL https://review.opendev.org/c/openstack/governance/+/831118 | 03:09 |
| opendevreview | Merged openstack/governance master: Appoint pangliye as Venus PTL https://review.opendev.org/c/openstack/governance/+/831120 | 03:09 |
| opendevreview | Merged openstack/governance master: Appoint Lance as OpenStack Chef PTL https://review.opendev.org/c/openstack/governance/+/831121 | 03:09 |
| opendevreview | Merged openstack/governance master: Appoint XueFeng as Senlin PTL https://review.opendev.org/c/openstack/governance/+/831122 | 03:10 |
| *** ykarel is now known as ykarel|mtg | 05:26 | |
| *** ykarel|mtg is now known as ykarel | 07:01 | |
| *** ykarel is now known as ykarel|away | 13:32 | |
| *** iurygregory_ is now known as iurygregory | 13:48 | |
| iurygregory | gmann, hey o/ do you have the defined slots for the tc-ptl interaction during the PTG? | 13:49 |
| gmann | iurygregory: hi, yeah we have booked the slot http://lists.openstack.org/pipermail/openstack-discuss/2022-March/027584.html | 13:50 |
| gmann | iurygregory: for TC-PTL it is Monday 14-16 UTC | 13:51 |
| iurygregory | gmann, ack I missed this email, ty! | 13:56 |
| gmann | iurygregory: np!, hope that time works for you | 13:56 |
| iurygregory | works =) | 13:57 |
| gmann | cool | 13:57 |
| dansmith | gmann: sorry forgot to circle back on that after the rendering fixes, I | 14:26 |
| dansmith | am +1 now | 14:26 |
| gmann | dansmith: thanks | 14:26 |
| dansmith | gmann: thanks for the review on the deprecation patch | 14:46 |
| dansmith | gmann: I replied if you can check and then I'll start on revisions | 14:46 |
| gmann | dansmith: sure, in internal meeting. will check in an 30 min from now | 14:50 |
| dansmith | ack thanks | 14:50 |
| gmann | dansmith: replied. | 15:22 |
| dansmith | gmann: thanks! | 15:47 |
| dansmith | gmann: okay doing this math, I think this is why I got caught up: | 15:58 |
| dansmith | gmann: if you deprecate something in a tick, then removal in the following tock would be quite aggressive | 15:58 |
| dansmith | so I think maybe we should alter that year math to say "if you deprecate in a tick, you can remove in the following tick, but not the intermediate tock" | 15:59 |
| dansmith | that's more in line with what we have today, and I think that's reasonable right? | 15:59 |
| dansmith | that way everyone gets ~12mo of warning | 15:59 |
| dansmith | everyone being, tock-tockers and just-tickers | 15:59 |
| fungi | also deprecating in a tock shouldn't happen, or should require two ticks to remove | 16:01 |
| dansmith | fungi: not sure about two ticks, but we noted informally that if you deprecate in a tock, you have to deprecate in the following tick explicitly for the notice | 16:03 |
| fungi | yeah, that's essentially what i meant | 16:04 |
| dansmith | ack | 16:04 |
| fungi | basically deprecating in a tock is pointless since you need it deprecated in the following tick and tock anyway and can't remove it until the second tick | 16:04 |
| dansmith | pointless in terms of timelines, but it may be better for bookeeping | 16:05 |
| dansmith | i.e. deprecate and then remember to note in the following renos, vs. "remind me in 6mo to deprecate this thing" | 16:05 |
| fungi | sure. it has a longer horizon than if you deprecate in a tick | 16:05 |
| fungi | if you deprecate in a tick then you can remove the feature in ~12mos. if you deprecate in a tock you can remove the feature in ~18mos. | 16:06 |
| dansmith | well, potentially you could do it much quicker, based on what we have now: | 16:07 |
| dansmith | if you deprecate just before a tock release, then you could remove as soon as the following tick is released, so ~6.1mo | 16:08 |
| dansmith | we're saying one tick is enough warning for just-tickers, because it's >=12mo before they need to account for the change | 16:08 |
| fungi | oh! i see, so you can remove in a tock, it just need to be deprecated in at least one tick | 16:11 |
| dansmith | yeah | 16:11 |
| gmann | dansmith: yes, deprecating in tick has to wait for removal until the start of the next tick development cycle. deprecating in tock(for some case) has to wait for removal until next tock with notify again in release notes in immediate tick | 16:12 |
| dansmith | yeah, cool | 16:12 |
| fungi | so yes, deprecate in a tick and removal in ~6mos. is possible. deprecate in a tock and you need ~12mos to remove | 16:12 |
| gmann | so for 1 tick things will be deprecated either way | 16:12 |
| fungi | i guess i'm counting "removal" from the perspective of release consumers, not from the perspective of when developers can merge changes | 16:13 |
| dansmith | fungi: yeah, and this document is more dev-focused I think, which is why I'm trying to make it sound as flexible as possible | 16:16 |
| fungi | makes sense | 16:17 |
| fungi | when it comes to messaging for our users, we'll presumably need to position it a little differently | 16:17 |
| gmann | yeah from developer perspective when we can merge the change, releases are always later than that. developer timeline matters if anyone using master | 16:17 |
| gmann | fungi: for users also, it will be ok as merged code is in release happening later than that expect anyone using master | 16:18 |
| fungi | for people consuming from the master branch, at least the release tag gives them somewhere safe to pause if they need to deal with that particular deprecation | 16:18 |
| dansmith | I'm putting "and operators get..." wording in here now, which I think will help clear it up for both sides | 16:20 |
| gmann | +1 | 16:21 |
| opendevreview | Dan Smith proposed openstack/project-team-guide master: Migrate deprecation tag to a document here https://review.opendev.org/c/openstack/project-team-guide/+/832126 | 16:25 |
| dansmith | see how that sits with you (all) ^ | 16:25 |
| fungi | clear as crystal, thanks! | 16:29 |
| dansmith | oh, I forgot to check the rendering.. hope that worked | 16:43 |
| * dansmith checks | 16:43 | |
| dansmith | hmm, not sure those sub-numberings are the best way to do that | 16:44 |
| gmann | dansmith: it can be list. I think we did numbering for tag things like number of things as requirement | 16:44 |
| dansmith | ah, I got it. they need to line up with the parent items | 16:46 |
| opendevreview | Dan Smith proposed openstack/project-team-guide master: Migrate deprecation tag to a document here https://review.opendev.org/c/openstack/project-team-guide/+/832126 | 16:47 |
| gmann | dansmith: lgtm, I think I can +W this or you want to wait for more reviews/feedback etc | 17:02 |
| dansmith | gmann: up to you | 17:02 |
| gmann | dansmith: ok, let's merge it and anyways we are going to discuss it in PTG if any change. | 17:02 |
| gmann | +W | 17:03 |
| dansmith | ack | 17:03 |
| opendevreview | Merged openstack/project-team-guide master: Migrate deprecation tag to a document here https://review.opendev.org/c/openstack/project-team-guide/+/832126 | 17:12 |
| dansmith | gmann: so you think now's the time for an email to the list about ^ ? | 17:12 |
| gmann | dansmith: I was thinking to email with 1. deprecation ^^ this and 2. testing both and saying we will discuss it in PTG too .. | 17:14 |
| gmann | or anything specific thing needs to be changed on this ? I think these two are main | 17:14 |
| dansmith | ack | 17:15 |
| dansmith | I'll work on a draft | 17:15 |
| gmann | dansmith: testing because other project can start doing skip level job based on your grenade one like mania did and they can list query or any challenge for PTG | 17:16 |
| gmann | thanks | 17:16 |
| dansmith | ack | 17:16 |
| dansmith | gouthamr: good to merge this now? https://review.opendev.org/c/openstack/manila/+/830277 | 17:45 |
| dansmith | tc-members: I am planning to send this regarding the release cadence and deprecation adjustments, but happy to take feedback first if anyone is willing to look: https://paste.opendev.org/show/b2K2MloYGGCB14PLyB87/ | 18:09 |
| gmann | dansmith: in 2nd paragraph these lines are little confusing. "If AA is our first | 18:14 |
| gmann | official "tick" release, then Yoga would be the current one, and Wallaby | 18:14 |
| gmann | would be the previous. As such, the job currently tests (successfully!) | 18:14 |
| gmann | a direct upgrade from Wallaby->Yoga." | 18:14 |
| gmann | as official testing we want to test Yoga->AA or AA -> CC ? | 18:14 |
| dansmith | well, I figured we have the testing in place now, we're hoping it will continue to work between now and AA unless something happens, but AA is where we commit to that support as a hard line | 18:15 |
| gmann | AA as commit to support means Yoga->AA as voting job | 18:16 |
| dansmith | so you think I should say "we're planning to test wallaby, yoga, through AA as if we already supported this" or something? | 18:16 |
| dansmith | okay, maybe say "as non-voting until then, but recommend projects make it voting ASAP" ? | 18:16 |
| gmann | yeah, we can state like "As AA is our first official tick release we need to target Yoga -> AA testing as voting" but we will start testing it from now onwards the wallaby->Yoga (newly added job)" | 18:18 |
| gmann | dansmith: in next cycle you mentioned to update to wallaby->AA ? it should be Yoga->AA | 18:18 |
| dansmith | oh yep yep | 18:19 |
| gmann | dansmith: and in Zed cycle during master, we will keep wallaby->Yoga only right? and then in AA master Yoga -> AA | 18:19 |
| gmann | basically in tock development cycle, no change in skip level job from that it was doing? then do we need to run on tock master ? | 18:20 |
| gmann | *from what it was.. | 18:20 |
| dansmith | right | 18:20 |
| dansmith | "We expect this to be a voting job in AA, making sure it works from Yoga->AA. Right now it tests Wallaby->Yoga for informational purposes. We would recommend projects enable that as voting, or define their own job to do similar testing as soon as possible. | 18:21 |
| dansmith | better? | 18:21 |
| gmann | +1. very clear. | 18:21 |
| gmann | and how we tell it for tock development cycle. "remove this job running on tock master gate" ? | 18:22 |
| dansmith | maybe s/expect/intend/ | 18:22 |
| gmann | +1 | 18:22 |
| dansmith | I dunno, I don't want to add too much detail.. if we are developing Z and Z isn't at the end of either sequence, it would follow that it's not relevant there right? | 18:23 |
| dansmith | maybe we can wait for someone to ask that.. :P | 18:23 |
| gmann | :) ok and we can remove when it become unnecessary testing in zed. | 18:24 |
| dansmith | ack, so this is the revised: https://paste.opendev.org/show/bDVU3CGPvOCvslBiWih3/ and I'll hold off a bit in case any other tc-members: have comments | 18:24 |
| gmann | and can you add one line also that current greande testing whic will be tick->tock to tock->tick will be unchanged for the operator upgrading to tock(current situation) | 18:24 |
| gmann | dansmith: ^ sorry 1 more comment :) sorry for late typing | 18:25 |
| dansmith | ah sure | 18:25 |
| dansmith | added "Note that existing grenade testing between each adjacent release remains unchanged in this scheme." | 18:27 |
| gmann | +1 | 18:27 |
| gmann | thanks dansmith | 18:28 |
| * dansmith nods | 18:28 | |
| gmann | dansmith: just a TODO note, after PTG when we all agreed on the testing plan, we can add the upgrading testing plan/expectation in this doc (may be few general upgrade testing copied from the removed upgrade tag doc) https://docs.openstack.org/project-team-guide/testing.html | 18:31 |
| dansmith | ack | 18:31 |
| gmann | dansmith: I have added all TODO/things to check/discuss in TC PTG etherpad, feel free to add more if there is any https://etherpad.opendev.org/p/tc-zed-ptg | 18:38 |
| dansmith | cool | 18:39 |
| gmann | dansmith: flow I am thinking in PTG 1. overview/explain/answer query in TC+PTL sessions on Monday 2. projects discuss their specific things during week 3. in TC PTG ^^ we figure out those TODO etc | 18:39 |
| gmann | is it fine? | 18:39 |
| gmann | if anything you want to move from TC sessions to TC+PTL we can do | 18:40 |
| dansmith | ah yeah, some early discussion, then back to projects to mull, and then end-of-week circle back to address concerns/ | 18:40 |
| gmann | yeah | 18:40 |
| dansmith | yeah makes sense | 18:40 |
| gmann | cool | 18:40 |
| *** odyssey4me is now known as Guest1716 | 18:49 | |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint Martin as Monasca PTL https://review.opendev.org/c/openstack/governance/+/831124 | 21:52 |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint Rong Zhu as Murano PTL https://review.opendev.org/c/openstack/governance/+/831125 | 21:53 |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint Rong Zhu as Solum PTL https://review.opendev.org/c/openstack/governance/+/831126 | 21:53 |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint Chen Ke as Watcher PTL https://review.opendev.org/c/openstack/governance/+/831127 | 21:53 |
| opendevreview | Ghanshyam proposed openstack/governance master: Appoint ge cong as Freezer PTL https://review.opendev.org/c/openstack/governance/+/831128 | 21:53 |
| opendevreview | Merged openstack/governance master: Appoint Martin as Monasca PTL https://review.opendev.org/c/openstack/governance/+/831124 | 22:08 |
| opendevreview | Merged openstack/governance master: Appoint Rong Zhu as Murano PTL https://review.opendev.org/c/openstack/governance/+/831125 | 22:09 |
| opendevreview | Merged openstack/governance master: Appoint Rong Zhu as Solum PTL https://review.opendev.org/c/openstack/governance/+/831126 | 22:10 |
| opendevreview | Merged openstack/governance master: Appoint Chen Ke as Watcher PTL https://review.opendev.org/c/openstack/governance/+/831127 | 22:14 |
| opendevreview | Merged openstack/governance master: Appoint ge cong as Freezer PTL https://review.opendev.org/c/openstack/governance/+/831128 | 22:15 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!