13:32:25 <jpena> #startmeeting rpm_packaging
13:32:26 <openstack> Meeting started Thu Nov  5 13:32:25 2020 UTC and is due to finish in 60 minutes.  The chair is jpena. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:32:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:32:29 <jpena> ping toabctl, dirk, apevec, jpena, number80, kaslcrof,  rha, hberaud, sboyron
13:32:30 <openstack> The meeting name has been set to 'rpm_packaging'
13:32:32 <jpena> #topic roll call
13:32:40 <hberaud> o/
13:32:48 <jpena> feel free to add any last-minute topic to the agenda at https://etherpad.opendev.org/p/openstack-rpm-packaging
13:32:52 <jpena> #chair hberaud
13:32:53 <openstack> Current chairs: hberaud jpena
13:38:08 <sboyron> o/
13:38:53 <jpena> #chair sboyron
13:38:54 <openstack> Current chairs: hberaud jpena sboyron
13:39:19 <jpena> we don't have any topic on the agenda, so let's go straight to the open floor
13:39:23 <jpena> #topic open floor
13:40:14 <jpena> Anything to discuss?
13:40:24 <hberaud> nothing special from side
13:40:32 <sboyron> nothing on my side.
13:40:35 <hberaud> my*
13:41:22 <sboyron> indeed, there is still this review : https://review.opendev.org/#/c/758990/
13:41:42 <sboyron> but I didn't find any time to work on it
13:41:59 <sboyron> Oops wrong one
13:42:31 <sboyron> Was thinking about this one : https://review.opendev.org/#/c/756383/
13:42:47 <hberaud> sboyron: I was wondering why you shared this link lol
13:43:07 <jpena> :)
13:43:17 <sboyron> jpena: you added some comments and asked for Joel if he had something to add
13:43:33 <jpena> I'll ping Joel again, in case he can add something
13:43:43 <sboyron> I think this could be great to continue working on it...
13:43:53 <hberaud> +1
13:44:01 <sboyron> Will do as soon as I'll have some time to dedicate on it.
13:44:09 <hberaud> same thing here
13:44:21 <hberaud> but don't hesitate to iterate over it
13:44:59 <hberaud> I mean to submit new PS on the top of it
13:45:03 <sboyron> your remark jpena is good (it was one of my point ;) ) regarding the fact it is not doing a "full" check
13:45:46 <sboyron> I think we should finished a version 1 of it not having the extra deps check
13:46:01 <hberaud> maybe we could split features through follow up patches
13:46:07 <sboyron> to ensure not requiring dependance that has been removed from the project
13:46:19 <hberaud> to avoid tunnel effect
13:46:27 <jpena> yes, that looks like a good feature for a follow-up patch
13:46:38 <hberaud> and to release often
13:46:43 <sboyron> I think it must be reworked to take care of your remark about virtualenv and non-voting, then merging it and develop new features after
13:46:51 <hberaud> and see what need to be improve or not
13:47:04 <jpena> agreed
13:47:06 <hberaud> +1
13:47:24 <hberaud> sboyron: do you want to manage this last iteration?
13:47:35 <hberaud> (venv + non-voting)
13:47:52 <sboyron> hberaud: yep I can, but not sure will find some thime this week :/
13:47:55 <sboyron> I'll try
13:47:57 <hberaud> np
13:48:28 <hberaud> I haven't lot of spare time too so
13:48:32 <sboyron> And one other point is, I would like to add tests on URL to avoid having to check at least if this return 404 issues.
13:48:46 <hberaud> ok
13:49:04 <hberaud> awesome
13:50:25 <sboyron> The big mix of several review modifying some URL and creating a lot of duplicates boring me to be honest
13:50:32 <sboyron> it's a big mess now
13:51:12 <hberaud> we can't really avoid that
13:51:32 <hberaud> the only manner is to formalize everything in one shot
13:51:42 <sboyron> I think we can limit it by ci checking if the URL is matching a specific pattern
13:52:23 <dirk> O/
13:52:33 <jpena> #chair dirk
13:52:34 <openstack> Current chairs: dirk hberaud jpena sboyron
13:52:50 <hberaud> I mean that people are not necessary aware of our check and could decide to submit patch even if checks exists
13:53:13 <dirk> Which check are we talking about?
13:53:29 <hberaud> doc url
13:53:42 <hberaud> the DDOS of url updates
13:53:57 <hberaud> recently submitted
13:54:01 <sboyron> Hi dirk, We was talking about adding a new doc URL check in CI to avoid having some URL patch pointing to nothing
13:54:10 <sboyron> at least
13:54:33 <hberaud> anyway a check can't hurt
13:54:40 <sboyron> or having a pattern to apply on the URL
13:55:10 <dirk> Agreed, the question is if we just want to check for 404 or for a particular pattern
13:55:42 <hberaud> IMO 404 is enough
13:55:45 <sboyron> that was my question indeed
13:56:38 <hberaud> at each cycle I seen people trying to update urls (lower-contraints by example) and back and forth with them each 2 weeks
13:56:56 <hberaud> here are similar patches
13:56:56 <dirk> I hope noone feels offended by the flood of url accesses then
13:58:01 <dirk> Although that should be fine if we have a distinct user agent set
13:58:18 <hberaud> this kind of check (404) could addressed against only the commited file
13:58:23 <hberaud> *files
13:58:38 <hberaud> to avoid flood
13:58:45 <dirk> Yep, indeed
13:58:59 <openstackgerrit> Merged openstack/rpm-packaging master: Remove setuotppls Requirement from karbor  https://review.opendev.org/758310
13:59:21 <hberaud> however if someone decide to update all of them in one shot then it could trigger a DDOS
13:59:57 <hberaud> so maybe the user agent is a good idea too
14:00:28 <hberaud> to avoid to ignore this possiblity
14:01:37 <sboyron> I think this test should be parformed only when the URL line is modified; otherwise it could block some other review if the doc site is down.
14:01:48 <sboyron> and it should limit at the maximum this url flood
14:01:50 <dirk> A single update doing all would still be fine I think
14:02:09 <dirk> The one-url-per-review is the annoying one
14:02:44 <dirk> Lots of clicking  for not a lot of sense other than what feels like gamification
14:02:47 <sboyron> dirk agreed for the one url per review ;)
14:03:25 <sboyron> but the most boring now is that the new patches are offently duplicating some other review not yet abandonned ...
14:04:30 <dirk> I am trying to cleanup duplicates by abandoning the newer one
14:05:05 <sboyron> ok
14:05:14 <sboyron> good luck ;)
14:05:58 <sboyron> I tried to point them everytime I found some...
14:06:18 <hberaud> +1 for the doc line modifed, however the doc site is constantly monitored and I don't expect to lot of failures on this point, I mean this is a rare case
14:06:58 <hberaud> recheck are acceptable too
14:08:04 <hberaud> feel free to introduce a related granular check
14:10:21 <hberaud> in this case I think that some functions of https://review.opendev.org/#/c/756383/ could become a lib for us and our tests instead of stay isolated within this test
14:10:56 <hberaud> by example retrieve the last commited files is something common
14:11:23 <hberaud> retrieving a specific modified line could be surrounded by a common feature too
14:11:48 <hberaud> and our tests could "source" these common libs
14:11:53 <dirk> The original idea was to use rpm-packaging-tools repo for this
14:12:14 <hberaud> I see
14:12:14 <dirk> So far it wasn't worth the cross repo dependency
14:12:26 <dirk> But we can start that
14:13:03 <hberaud> on openstack/releases similar things are centralized in our repo
14:13:11 <dirk> To be honest retrieving the list of modified files is just a one liner
14:13:28 <hberaud> yep
14:14:12 <dirk> That's a good point, we need to build some release tooling
14:14:19 <hberaud> example https://github.com/openstack/releases/blob/master/tools/functions
14:14:51 <openstackgerrit> Merged openstack/rpm-packaging master: update reno Uniform Resource Locator  https://review.opendev.org/757700
14:15:41 <hberaud> and an example of usage => https://github.com/openstack/releases/blob/56ad9230f4ec97ca05380699870dcd9531dd0d27/tools/process_auto_releases.sh#L97
14:16:01 <dirk> So how about starting a collection of functions?
14:16:02 <hberaud> sourced here => https://github.com/openstack/releases/blob/56ad9230f4ec97ca05380699870dcd9531dd0d27/tools/process_auto_releases.sh#L35
14:16:29 <dirk> When that grows we can take the next step
14:16:31 <hberaud> it could be a follow up of https://review.opendev.org/#/c/756383/
14:16:38 <hberaud> yes sure
14:16:51 <hberaud> I think it's to early for now
14:17:09 <dirk> Yep, or start with a functions for this check
14:17:14 <dirk> Both is fine for me
14:17:33 <hberaud> but when I see our discussions I imagine that something like this will emerge soon
14:18:20 <hberaud> as sboyron propose other check with similar functionalities
14:18:24 <dirk> Yep
14:18:28 <sboyron> +1
14:18:38 <dirk> Let's do it incrementally
14:18:44 <hberaud> +1
14:18:51 <hberaud> that's all for me
14:19:28 <dirk> I have a topic
14:19:42 <hberaud> the floor is yours
14:19:45 <dirk> We still have some older branches around, like newton
14:20:10 <dirk> And currently suse ci still handles it, although likely not successful
14:20:15 <hberaud> I think they could be removed
14:20:48 <jpena> +1 to removing old branches (after tagging their last commit as -eol)
14:20:50 <hberaud> I seen similar discussion with queens/pike and octavia EM to EOL branches
14:21:20 <sboyron> yes can be removed
14:21:22 <hberaud> where octavia faced zuul failures
14:21:30 <hberaud> due to EOL branches
14:21:40 <dirk> I suggest to close newton and ocata
14:21:44 <hberaud> +1
14:21:51 <sboyron> +1
14:22:34 <dirk> Okay, so I will try to figure out how to push tags
14:22:39 <hberaud> this is a specific corner case of EM
14:23:46 <hberaud> previously EOL branches was automatically removed but since EM stale branches remains
14:24:55 <dirk> Which I think is fine as long as it still has activity
14:26:05 <jpena> dirk: we can push tags just doing "git push gerrit tag xxxx" after it's created locally
14:26:15 <hberaud> and as long of QA support if too
14:26:17 <jpena> you're in the release group, see https://review.opendev.org/#/admin/groups/2109,members
14:26:23 <hberaud> s/if/it/
14:27:50 <jpena> #agreed newton and ocata branches will be closed
14:29:47 <jpena> if there's nothing else to discuss, we can close the meeting (it's time!)
14:30:38 <sboyron> nothing from my side
14:31:21 <dirk> Sounds good
14:31:33 <dirk> Thanks for the productive meeting!
14:31:39 <jpena> #endmeeting