| *** ysandeep|out is now known as ysandeep | 04:16 | |
| *** ykarel|away is now known as ykarel | 05:04 | |
| *** ysandeep is now known as ysandeep|brb | 05:52 | |
| *** amoralej|off is now known as amoralej | 06:25 | |
| *** ysandeep|brb is now known as ysandeep | 06:41 | |
| *** ysandeep is now known as ysandeep|lunch | 08:08 | |
| *** ykarel is now known as ykarel|lunch | 09:05 | |
| *** ysandeep|lunch is now known as ysandeep | 09:19 | |
| opendevreview | Vishal Manchanda proposed openstack/releases master: Release horizon 20.2.0(Yoga) https://review.opendev.org/c/openstack/releases/+/815334 | 09:50 |
|---|---|---|
| *** ykarel|lunch is now known as ykarel | 10:19 | |
| ttx | elodilles, hberaud: see draft relmgt position on 1-year releases at https://etherpad.opendev.org/p/relmgt-position-1y-releases | 10:33 |
| ttx | Let me know if I missed anything, or if there is something you disagree with | 10:34 |
| hberaud | ttx: ack, I'll have a look soon | 10:46 |
| *** marios is now known as marios|afk | 10:47 | |
| elodilles | ttx: thanks, will read today | 11:13 |
| *** ysandeep is now known as ysandeep|afk | 11:13 | |
| *** marios|afk is now known as marios | 11:21 | |
| opendevreview | Merged openstack/releases master: Release horizon 20.2.0(Yoga) https://review.opendev.org/c/openstack/releases/+/815334 | 11:29 |
| *** ysandeep|afk is now known as ysandeep | 11:54 | |
| *** ykarel_ is now known as ykarel | 12:01 | |
| *** amoralej is now known as amoralej|lunch | 12:39 | |
| hberaud | ttx: excellent draft! | 13:09 |
| hberaud | ttx: all the main points are present (stable branches, the naming rotation, cwi vs cwrc). I wonder if we should also warn about the impact for PTL/liaison rotation lifespan from on cyle to another | 13:11 |
| hberaud | I mean even if PTL election is not our scope, the release liaison topic is under our umbrella | 13:12 |
| *** amoralej|lunch is now known as amoralej | 13:14 | |
| hberaud | It will require to find release liaisons candidates who will voluntarring for 1 year too | 13:14 |
| hberaud | Concerning the benefits for the end users and customers, I totally agree that they are more looking for LTS release cadence than a browser release cadence. | 13:16 |
| hberaud | Less "stable branches", supported more longer, and with an increased lifespan, will be benefit to them. | 13:18 |
| hberaud | and will benefit to their business and their cost management | 13:19 |
| hberaud | ttx: also, beyond the cwi vs cwrc topic, you could speak about the current trend that occur within the project teams who try to move deliverables into the independent release model to be less impacted by coordinated release. The one year lifespan is a part of the solution because it will reduce the number of stable branches to maintain and so it will reduce the pain this | 13:30 |
| hberaud | work and it will give more time for the current series | 13:30 |
| hberaud | ttx: this last topic (the trend to move to the independent model) could be a part of the solution for http://lists.openstack.org/pipermail/openstack-discuss/2021-September/024705.html | 13:36 |
| hberaud | I mean this argument could be a backer for the extended lifespan | 13:38 |
| *** kopecmartin is now known as kopecmartin|pto | 14:00 | |
| ttx | Good point on PTL rotation... not really a release thing | 14:05 |
| ttx | but I can add it in | 14:05 |
| smcginnis | I'm not so sure about that "will voluntarring for 1 year" part. Release liaisons can be changed at any point. | 14:05 |
| smcginnis | So that seems more like an operational detail than something that needs to be called out in that write up. | 14:06 |
| hberaud | smcginnis: even for DPL? | 14:06 |
| ttx | yes you change when you want | 14:06 |
| hberaud | ok | 14:06 |
| ttx | it's better if someone does the full release, I guess | 14:06 |
| smcginnis | True | 14:06 |
| ttx | but definitely not a commitment | 14:06 |
| hberaud | My main concern was about the DPL governance model | 14:06 |
| hberaud | where the liaisons are the pilar of the governance for these teams | 14:07 |
| hberaud | pilars | 14:07 |
| smcginnis | I see them more as just a representative from the team. The team can decide when they need a release. It shouldn't really matter if that representative changes throughout the cycle. | 14:08 |
| smcginnis | Maybe I should put "shouldn't really matter" in quotes. :) | 14:08 |
| hberaud | np :) | 14:08 |
| *** ysandeep is now known as ysandeep|out | 14:17 | |
| ttx | hberaud: ok I added a mention of independent deliverables, as well as PTL/release liaison commitment impact | 14:22 |
| hberaud | thx | 14:43 |
| *** ykarel is now known as ykarel|away | 15:00 | |
| elodilles | ttx: I also like the draft you wrote about 'relmgmt position about the 1 year long release cycle'! in general I agree what you described there. and as Hervé said it is good that you clarified the cadence of stable maintenance. 24 months practically means 2 maintained stable branch (except for about 1 month per year, where we'll have 3 maintained stable branch, if we follow the current | 15:47 |
| elodilles | 'transition ~1 month after the release to EM'), which sounds reasonable. all in all, this looks all good to me, too! thanks again! | 15:47 |
| elodilles | I also consider the 'release liaison' role more flexible than the PTL role (similarly, like Sean wrote). a 1 year long PTL role maybe requires greater determination, though. | 15:53 |
| *** marios is now known as marios|out | 15:56 | |
| ttx | yep, but that's more of a TC discussion | 16:41 |
| ttx | elodilles: The next step would be to send it to the TC, which can be done in multiple ways (email to the list with [tc] tagged, addition to a TC meeting agenda). If email, I can send it but it might be more appropriate coming from the relmgt team ptl | 16:42 |
| ttx | so let me know what you prefer and if you're comfortable sending that | 16:43 |
| elodilles | well, i guess usually the PTL sends this kind of mails, but let's be honest, probably it's more authentic if you send it o:) | 16:57 |
| *** amoralej is now known as amoralej|off | 17:29 | |
| fungi | the key rotation has merged just now, so keep an eye out for signing errors with any release jobs approved after this point | 17:43 |
| fungi | also it should be safe to approve the releases site change with the new key copy/fingerprint | 17:44 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!