Wednesday, 2021-10-27

*** ysandeep|out is now known as ysandeep04:16
*** ykarel|away is now known as ykarel05:04
*** ysandeep is now known as ysandeep|brb05:52
*** amoralej|off is now known as amoralej06:25
*** ysandeep|brb is now known as ysandeep06:41
*** ysandeep is now known as ysandeep|lunch08:08
*** ykarel is now known as ykarel|lunch09:05
*** ysandeep|lunch is now known as ysandeep09:19
opendevreviewVishal Manchanda proposed openstack/releases master: Release horizon 20.2.0(Yoga)
*** ykarel|lunch is now known as ykarel10:19
ttxelodilles, hberaud: see draft relmgt position on 1-year releases at
ttxLet me know if I missed anything, or if there is something you disagree with10:34
hberaudttx: ack, I'll have a look soon10:46
*** marios is now known as marios|afk10:47
elodillesttx: thanks, will read today11:13
*** ysandeep is now known as ysandeep|afk11:13
*** marios|afk is now known as marios11:21
opendevreviewMerged openstack/releases master: Release horizon 20.2.0(Yoga)
*** ysandeep|afk is now known as ysandeep11:54
*** ykarel_ is now known as ykarel12:01
*** amoralej is now known as amoralej|lunch12:39
hberaudttx: excellent draft!13:09
hberaudttx: 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 another13:11
hberaudI mean even if PTL election is not our scope, the release liaison topic is under our umbrella13:12
*** amoralej|lunch is now known as amoralej13:14
hberaudIt will require to find release liaisons candidates who will voluntarring for 1 year too13:14
hberaudConcerning 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
hberaudLess "stable branches", supported more longer, and with an increased lifespan, will be benefit to them.13:18
hberaudand will benefit to their business and their cost management13:19
hberaudttx: 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 this13:30
hberaudwork and it will give more time for the current series13:30
hberaudttx: this last topic (the trend to move to the independent model) could be a part of the solution for
hberaudI mean this argument could be a backer for the extended lifespan13:38
*** kopecmartin is now known as kopecmartin|pto14:00
ttxGood point on PTL rotation... not really a release thing14:05
ttxbut I can add it in14:05
smcginnisI'm not so sure about that "will voluntarring for 1 year" part. Release liaisons can be changed at any point.14:05
smcginnisSo that seems more like an operational detail than something that needs to be called out in that write up.14:06
hberaudsmcginnis: even for DPL?14:06
ttxyes you change when you want14:06
ttxit's better if someone does the full release, I guess14:06
ttxbut definitely not a commitment14:06
hberaudMy main concern was about the DPL governance model14:06
hberaudwhere the liaisons are the pilar of the governance for these teams14:07
smcginnisI 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
smcginnisMaybe I should put "shouldn't really matter" in quotes. :)14:08
hberaudnp :)14:08
*** ysandeep is now known as ysandeep|out14:17
ttxhberaud: ok I added a mention of independent deliverables, as well as PTL/release liaison commitment impact14:22
*** ykarel is now known as ykarel|away15:00
elodillesttx: 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
elodillesI 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|out15:56
ttxyep, but that's more of a TC discussion16:41
ttxelodilles: 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 ptl16:42
ttxso let me know what you prefer and if you're comfortable sending that16:43
elodilleswell, 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|off17:29
fungithe key rotation has merged just now, so keep an eye out for signing errors with any release jobs approved after this point17:43
fungialso it should be safe to approve the releases site change with the new key copy/fingerprint17:44

Generated by 2.17.2 by Marius Gedminas - find it at!