17:00:11 <hberaud> #startmeeting releaseteam
17:00:18 <openstack> Meeting started Thu Jan 14 17:00:11 2021 UTC and is due to finish in 60 minutes.  The chair is hberaud. Information about MeetBot at http://wiki.debian.org/MeetBot.
17:00:18 <hberaud> #link https://etherpad.opendev.org/p/wallaby-relmgt-tracking Agenda
17:00:18 <ttx> o/
17:00:19 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
17:00:22 <openstack> The meeting name has been set to 'releaseteam'
17:00:22 <hberaud> Ping list: ttx armstrong elod
17:00:27 <armstrong_> o/
17:00:28 <hberaud> We're way down on line 218 now.
17:00:33 <hberaud> Will just wait a couple minutes for folks.
17:01:19 <armstrong_> ok
17:02:01 <ttx> sure
17:03:17 <elod> o/
17:04:00 <hberaud> Ok let's go!
17:04:09 <hberaud> #topic Review task completion
17:04:16 <hberaud> Victoria Cycle-Trailing Release Deadline => done
17:05:05 <hberaud> And I think we can move directly to the next topic as it will speak about the membership freeze
17:05:23 <hberaud> #topic Discuss findings of governance consistency checks above and resulting necessary actions
17:05:38 <hberaud> ttx, armstrong_ : the floor is yours
17:05:44 <ttx> alright
17:06:02 <ttx> So the goal of this is to make sure we are aligned between the releases and governance repos
17:06:08 <ttx> And, as always, we are not
17:06:13 <hberaud> :)
17:06:35 <ttx> First, things that are in governance, but not in releases deliverable files
17:06:41 <ttx> karbor, karbor-dashboard, python-karborclient: newly-abandoned project. Will be fixed once https://review.opendev.org/c/openstack/governance/+/767056 merges
17:07:10 <hberaud> ack
17:07:14 <ttx> ansible-role-atos-hsm, ansible-role-thales-hsm: New barbican deliverables, we should probably reach out to barbican team ask if we should plan to release for Wallaby
17:07:38 <hberaud> any takers?
17:07:44 <ttx> and if yes, craete deliverable files for those
17:07:44 <hberaud> I can ping them
17:07:54 <ttx> etcd3gw: New oslo deliverable, see with oslo team if we should plan to release for Wallaby. or make it _independent
17:08:06 <hberaud> I think we can move it to independent
17:08:18 <hberaud> but before I'll bring that to the next oslo meeting
17:08:21 <ttx> ok
17:08:24 <bnemec> It was previously being released independently, so that makes sense.
17:08:27 <hberaud> just to confirm
17:08:39 <ttx> Now onto more problematic ones
17:08:42 <hberaud> bnemec: thanks for the heads up
17:08:51 <ttx> barbican-ui: (Added Oct 2019) -- never released yet, was not ready yet for ussuri and victoria. maybe we should abandon this instead of waiting?
17:09:14 <ttx> it's been basically two cycles tat we have waited for it to be in releasable shape
17:09:32 <ttx> hberaud: maybe you can ask about it while you ping barbican folks?
17:09:33 <hberaud> I don't see reason to continue more further if nothing should be released anymore
17:09:37 <hberaud> yes
17:09:42 <ttx> It was never released
17:09:58 <hberaud> It was the same scenario with few tripleo repo
17:10:02 <hberaud> repos
17:10:13 <ttx> so unless they are still making progress we might want to deprecate it
17:10:24 <ttx> Same question for the next one:
17:10:42 <ttx> openstack-tempest-skiplist:  (Added Mar 20, 2020) never released yet, was not ready yet for ussuri and victoria. maybe we should abandon this instead of waiting? we should ask gmann's opinion
17:11:04 <ttx> or maybe it's not meant to be released, idk
17:11:20 <ttx> Third in this "not eady yet for a long time" category:
17:11:28 <ttx> js-openstack-lib: (Added January 9, 2020) -- never released yet, was not ready for ussuri or victoria. maybe we should abandon this instead of waiting. Ask OpenStackSDK
17:11:36 <hberaud> ok
17:11:53 <hberaud> I'll ping all these teams to clarify the situation
17:11:54 <ttx> Finally: monasca-ceilometer, monasca-log-api: Released in train but not released in ussuri nor victoria. Should be deprecated in governance? Ask Monsaca
17:12:08 <hberaud> same thing
17:12:12 <ttx> right
17:12:27 <ttx> Then we have a bunch that are in deliverable files but no longer in project teams
17:12:36 <ttx> enderspec, rpm-packaging, pymod2pkg: _independent deliverables from RPM Packaging team. Should be marked release-model: abandoned ? to be discussed as team policy
17:12:48 <ttx> So they used to be a project team, now a SIG
17:13:02 <ttx> We could make them "abandoned" but that would not be technically correct
17:13:03 <hberaud> concerning the rpm-packaging stuff, I'm a core team member there so I'll bring that in the next meeting
17:13:09 <ttx> we have no good answer for that scenario
17:13:44 <ttx> In the past we did remove the files completely, so that they would not show as "abandoned"
17:13:46 <hberaud> Yes it could be useful to clarify the situation with the TC about this scenario
17:14:17 <ttx> Not sure that should involve the TC... It's about how we want those to show up in the releases website
17:14:19 <hberaud> Maybe we should update a bit the SIG model to match this case
17:14:31 <hberaud> ah I see
17:14:59 <ttx> Newer releases will not appear in the site, so my preference is to remove them completely so that we do not list an old release
17:15:07 <gmann> ttx: hberaud openstack-tempest-skiplist is under TripleO governance, may be we can ask marios or Chandan : https://github.com/openstack/governance/blob/2bdd9cff00fb40b2f95b66cad47ae1cfd14a2f1b/reference/projects.yaml#L3069
17:15:15 <hberaud> So lemme discuss about with the team member, but the file removing seems a good option
17:15:32 <ttx> and also so that they  do not appear as "abandoned"
17:15:42 <ttx> that is what we did for other SIG transitions.
17:15:45 <hberaud> yes it could be misleading
17:16:07 <ttx> basically make it look like it was produced by a SIG all the time. It's OK for _independenmt deliverables
17:16:19 <ttx> If they were series deliverables we would keep them arounmd
17:16:45 <hberaud> I see
17:16:47 <ttx> Now that I think of it, it's the only good answer
17:17:03 <ttx> and I remember that's how we handled the case last time it popped up
17:17:16 <ttx> so.. maybe a non-issue. I'll file the file removals
17:17:25 <hberaud> Ack, thanks
17:17:44 <ttx> ok done
17:17:52 <ttx> I'll add those tasks on next week
17:18:38 <hberaud> Thanks, I already added few of them
17:19:13 <hberaud> #topic Discussing Victoria Cycle-Trailing Release Deadline
17:19:35 <hberaud> Nothing more to add
17:19:42 <hberaud> I forgot to remove that section
17:19:59 <hberaud> So we can move on
17:20:05 <hberaud> #topic Encouraging projects to apply for tag 'assert:supports-api-interoperability'
17:20:33 <hberaud> You surely gmann's ML thread http://lists.openstack.org/pipermail/openstack-discuss/2021-January/019814.html
17:20:54 <hberaud> I've a couple of thinking/questions related to that
17:21:10 <hberaud> Only Nova seems to support it for now and they start each new series with a new major version and that doesn't reflect this tag as a major version could mean that the backward compat is broken
17:21:28 <hberaud> Do we need/want to clarify this point on our side?
17:21:52 <hberaud> Do we should suggest a governance updates to reflect the semver part? This tag seems to have been introduced long time ago and AFAIK nobody complained about the semver part
17:22:19 <hberaud> So to summarize do we want/need to raise our banner in this thread?
17:22:23 <gmann> hberaud: this tag is for API versioning not the service versioning, we can see both are different.
17:22:41 <ttx> not sure there is anything we should do...
17:22:53 <hberaud> yes but as semver reflect this too maybe we have some grey area
17:23:12 <gmann> in API versioning (this tag), we assert that all API changes happening should be under some version so that they can be discovered.
17:23:25 <hberaud> ok
17:24:09 <gmann> and versioning for API is quite open like it can be semver way or microversion way or anything else, as long as they are discoverable it is good
17:24:24 <hberaud> As nobody complained previously I think we can continue like that
17:24:28 <hberaud> ack
17:24:48 <hberaud> Thanks for details
17:25:12 <hberaud> fair enough
17:25:20 <hberaud> #topic Tempest stein-last
17:26:40 <hberaud> So 1) gmann documented the "-last" tags, 2) we proposed a patch to update our machinery accordingly 3) all patches have been updated accordingly to 1 and 2
17:26:58 <gmann> on 1st part,  I just updated the project-team-guide patch with correct link, if you can check it again https://review.opendev.org/c/openstack/project-team-guide/+/769821
17:27:08 <hberaud> gmann: ack
17:27:22 <gmann> and ttx ^^
17:27:28 <hberaud> As 2 depends-on 1 I think it is safe to start to approve 3
17:27:51 <hberaud> *safe enough
17:28:22 * hberaud look at https://review.opendev.org/c/openstack/project-team-guide/+/769821
17:28:35 <ttx> +2
17:28:42 <gmann> thanks
17:29:07 <hberaud> +1
17:29:48 <hberaud> Ok I think we can move on
17:30:05 <hberaud> #topic The pip's resolver issue
17:30:38 <hberaud> Just a friendly reminder about the doc/pip issue, we are still in "orange" status
17:31:00 <ttx> I would keep it that way until we can get the exception list a bit smaller
17:31:32 <ttx> although....
17:31:33 <hberaud> +1
17:31:39 <hberaud> Can't hurt
17:31:46 <ttx> maybe we should check which of those are under release-management
17:31:53 <hberaud> Yes
17:32:01 <ttx> Like for example we should not wait on openstack/api-site
17:32:12 <ttx> since it's not released, so it should not block return to GREEN
17:32:28 * hberaud check the list
17:32:42 <ttx> So, maybe change the topic for the ones that are release-management:none
17:32:58 <ttx> openstack/contributor-guide
17:33:18 * ttx does a quick check
17:33:46 <ttx> openstack/release-test
17:33:56 <ttx> openstack/i18n
17:34:03 <hberaud> I think that all the monasca* are under our scope
17:34:05 <ttx> openstack/os-service-types
17:34:12 <hberaud> and some of them are failing
17:34:29 <hberaud> telemetry, solum too
17:34:38 <hberaud> pycadf
17:34:41 <ttx> the rest are "releasable" so the list is not empty yet
17:34:57 <hberaud> Yes it's worth to stay Orange for now
17:35:01 <ttx> could you update the topic on the ones we should not care about?
17:35:18 <ttx> so that the list only contains ones we care about?
17:35:36 <ttx> (from a green/orange standpoint)
17:35:59 <hberaud> The list contains ~8-9 projects that we care about
17:36:22 <hberaud> or maybe a bit more
17:36:43 <ttx> I just listed the ones we should not care about
17:36:55 <hberaud> awesome
17:37:10 <ttx> contributor-guide release-test i18n os-service-types api-site
17:37:12 <hberaud> I was thinking to generate a dedicated dashboard
17:38:09 <hberaud> I'll reply on the ML to share them more widely
17:38:21 <ttx> ok
17:39:03 <hberaud> Ok move on
17:39:10 <hberaud> #topic Assign R-12 tasks
17:40:09 <hberaud> Ok everything seems already assigned
17:40:47 <hberaud> Any volunteer on some of them?
17:41:47 <hberaud> Else, is not an issue and we can continue with that
17:42:24 <hberaud> Ok move on
17:42:34 <hberaud> #topic Review countdown email contents
17:42:43 <hberaud> https://etherpad.opendev.org/p/relmgmt-weekly-emails
17:43:11 <hberaud> I ignored a section of the email template
17:43:36 <hberaud> And I proposed to remove her https://review.opendev.org/c/openstack/releases/+/770735
17:44:13 <hberaud> Let me know if it make sense to you, c.f the commit message for further details
17:44:17 <ttx> ok
17:45:15 <hberaud> I didn't see this list during victoria either
17:45:30 <hberaud> (the project list)
17:47:15 <hberaud> Any comment?
17:47:26 <ttx> nope, content looks good
17:47:33 <hberaud> ack, thanks
17:47:46 <hberaud> then...
17:47:52 <hberaud> #topic Open floor
17:48:02 <hberaud> Anything else to discuss today?
17:48:17 <ttx> I just approved the stein-last things that were ready
17:48:26 <hberaud> thanks
17:48:26 <elod> a heads-up from me maybe,
17:48:41 <hberaud> elod: the floor is yours
17:48:44 <elod> though train-em is far (05-12)
17:49:25 <elod> (as I said before) I'm planning to generate train release patches
17:49:34 <hberaud> We do you suggest?
17:49:46 <elod> maybe some time after milestone-2?
17:49:48 <hberaud> s/We/What/
17:50:17 <hberaud> LGTM
17:50:27 <hberaud> Could be in February/March
17:50:42 <hberaud> elod: Is it ok for you ^
17:50:46 <hberaud> ?
17:50:54 <elod> I thought maybe end of next week, the week after :)
17:50:59 <elod> so a bit sooner :)
17:51:03 <hberaud> Yes
17:51:19 <elod> but if you think I can wait with that till Feb or March
17:51:58 <hberaud> What do you plan to release exactly? everything that need to be released?
17:52:21 <elod> where there are unreleased patches, yes
17:52:22 <hberaud> I mean all the changes not yet released?
17:52:31 <elod> exactly
17:52:43 <hberaud> So you're right ASAP could be better
17:52:57 <elod> as smcginnis did in july (?)
17:52:59 <hberaud> It will avoid loaded agenda
17:53:28 <elod> hberaud: yes, ack
17:53:34 * hberaud check the agenda
17:54:41 <hberaud> Yes definitely, March will be FF and M3, and we will be heavy loaded
17:55:03 <hberaud> +1 for M2 the week after
17:55:14 <elod> hberaud: ack
17:55:23 <elod> thanks, that's it :X
17:55:53 <hberaud> elod: thanks to have bring that here
17:56:00 <hberaud> Anything else?
17:56:16 <hberaud> elod: Just one thing
17:56:37 <hberaud> I think it could be worth to send a friendly reminder
17:56:41 <hberaud> about that
17:57:09 <elod> hberaud: ok
17:57:15 <hberaud> elod: do you want to handle that as you did with stein?
17:57:54 <hberaud> It will inform the teams that train will be released soon
17:58:04 <elod> hberaud: just to be clear: this is not the 'final-release-before-[4~em'
17:58:08 <elod> :)
17:58:15 <hberaud> Yep
17:58:34 <hberaud> But it could let's a chance to them to prioritize their reviews
17:59:09 <hberaud> That's all for me
17:59:27 <hberaud> OK, thanks everyone. Almost there!
17:59:46 <hberaud> We consumed all our time
17:59:58 <ttx> thanks hberaud !
18:00:10 <elod> thanks!
18:00:27 <hberaud> #endmeeting