| opendevreview | Adam McArthur proposed openstack/oslo.service master: Removing oslo_wsgi eventlet dependency https://review.opendev.org/c/openstack/oslo.service/+/914927 | 00:00 |
|---|---|---|
| opendevreview | Adam McArthur proposed openstack/oslo.service master: Removing oslo_wsgi eventlet dependency https://review.opendev.org/c/openstack/oslo.service/+/914927 | 01:13 |
| opendevreview | Adam McArthur proposed openstack/oslo.service master: Removing oslo_wsgi eventlet dependency https://review.opendev.org/c/openstack/oslo.service/+/914927 | 01:36 |
| tkajinam | hberaud, o/ I found that rdo still ships eventlet 0.33.3 which contains a few bugs recently fixed. I think we have to propose bumping the version in fedora but do you have any recommendation about the version used there ? | 07:39 |
| tkajinam | hberaud, ideally we can use 0.35.1, which is currently in u-c but we suspect fedora may prefer having the latest version which is 0.36.1 | 07:40 |
| frickler | tkajinam: thanks for the indirect reminder, we'll have 0.36.1 in u-c in about 2h, see https://review.opendev.org/c/openstack/requirements/+/914256 | 07:47 |
| tkajinam | frickler, nice :-) | 07:48 |
| tkajinam | after discussion in #rdo we propose 0.35.1 initially but if that bumps goes smooth then 0.36.1 may be still a good option | 07:48 |
| hberaud | tkajinam: I recently released eventlet 0.36.1, if possible I'd suggest using this one | 08:21 |
| tkajinam | ok | 08:21 |
| tkajinam | we'll see if we can use the version in u-c first and them may later attempt further bump. | 08:22 |
| hberaud | 0.35.1 is a good version, 0.36.0 is a buggy version, 0.36.1 fix a bug introduced by 0.36 | 08:22 |
| tkajinam | yeah | 08:23 |
| hberaud | though 0.36 fix an important bug in the new asyncio hub | 08:24 |
| tkajinam | is that one of the prep works to introduce asyncio, right ? | 08:24 |
| hberaud | so yeah 0.36.1 is a must have | 08:24 |
| hberaud | nope | 08:24 |
| hberaud | Asyncio has been introduced around 0.34 IIRC | 08:25 |
| tkajinam | ok | 08:25 |
| hberaud | we made more than 15 releases in the last 3 months | 08:25 |
| tkajinam | we may eventually replace it at some point but getting it back on healthy maintenance track is nice. good work done by you and a few other folks like Sean | 08:27 |
| hberaud | if you want details about all the releases (since they gave us the writing rights) you can use this label https://github.com/eventlet/eventlet/issues?q=is%3Aissue+is%3Aclosed+label%3Arelease | 08:27 |
| hberaud | thanks | 08:28 |
| hberaud | in all the case we can't replace eventlet without first get it back on an healthy maintenance track | 08:29 |
| hberaud | that wouldn't be possible | 08:29 |
| tkajinam | ah, thanks for the query. just book-marked it | 08:29 |
| tkajinam | yeah. otherwise we may need a folk which causes another mess | 08:30 |
| hberaud | I don't know if you use RSS feeds but you can subscribe to git tags and releases | 08:30 |
| hberaud | (from github) | 08:31 |
| hberaud | I use this github feature to track the updates of the libs that we use | 08:31 |
| hberaud | I use freshrss | 08:31 |
| tkajinam | oh that sounds nice | 08:32 |
| hberaud | https://www.freshrss.org/ | 08:32 |
| tkajinam | while we may catch upcoming incompatibility with it, another challenge is that we often see problems caused by "inactive" project and finding such projects by rss feed is a bit tricky | 08:32 |
| tkajinam | because you don't receive any update about these repos but these become silently broken/dead/etc ... X-( | 08:33 |
| hberaud | hence you are automatically informed of the latest changes for the libs where you have personal interests | 08:33 |
| hberaud | indeed | 08:33 |
| tkajinam | yeah. it'd be useful for some core libs with active update | 08:33 |
| tkajinam | and then we may check git blame of u-c file to find out inactive repos | 08:33 |
| hberaud | some of my tracking are pymemcache, dogpile, pyamqp | 08:34 |
| hberaud | your git blame idea is a good idea | 08:35 |
| hberaud | that would be nice to have a dashboard where you sync your reqs and where updates are listed and where inactive libs are highligthed | 08:36 |
| hberaud | that won't be too difficult to create a kind of tool at the web app format | 08:37 |
| tkajinam | yeah | 08:37 |
| hberaud | even, maybe, it already exists a similar tool | 08:37 |
| tkajinam | though being a 'CLI' person I may probably start with grep like; https://paste.opendev.org/show/bNpOdZkui90O1LbriZo9/ | 08:38 |
| hberaud | yeah in an openstack your tricks do the job | 08:38 |
| hberaud | *context | 08:38 |
| hberaud | added your command to my bookmarks :) | 08:39 |
| hberaud | you can even propose a related tool embdded in openstack/requirements | 08:40 |
| tkajinam | yeah | 08:40 |
| hberaud | I don't think we are the only ones to search for such kind of tool | 08:41 |
| hberaud | openstack/requirements already contains a tools directory with some tooling | 08:42 |
| hberaud | github seems really flaky today | 08:46 |
| hberaud | error 500 since a couple of minutes | 08:47 |
| tkajinam | yeah | 08:48 |
| tkajinam | maybe they are applying their AI to find out another xz attack ? :-P | 08:48 |
| hberaud | lol | 08:48 |
| hberaud | the vlc PTL explained in a youtube video that, one day, someone tried to stole him a physical access on his laptop during a presentation he made at a conf | 08:52 |
| tkajinam | that reminds me of how encrypting disk data is important | 08:54 |
| hberaud | fortunately for him, he seen the thief and his pgp keys were protected by password etc... If I correctly understood his session remained opened without him in front of his laptop | 08:54 |
| hberaud | totally and signing too | 08:54 |
| hberaud | especially when you work on important OS project | 08:55 |
| hberaud | he also explained that he often received weird patches. He often have security suspission | 08:56 |
| hberaud | anyway we live in a cruel world :) | 08:57 |
| tkajinam | crazy | 08:59 |
| tkajinam | we''ll see how everything goes, but it's clearly showing that we are at another turning point | 08:59 |
| hberaud | Entropy of systems increase with time. This rule applies to codes and projects. The more the entropy the less the security. | 09:03 |
| tkajinam | yeah. totally makes sense | 09:04 |
| hberaud | The strength of a chain is equal to that of its least strong link. The slightest application is made of several layers. Each layer is a link in that chain. Some of them are possibly weaks links. Some people are earn money at finding those links. | 09:10 |
| hberaud | Q.E.D | 09:11 |
| tkajinam | +1 | 09:17 |
| frickler | https://www.githubstatus.com/ they are working on it it seems. typical friday stuff ;) | 09:17 |
| tkajinam | Quick fix to make people work on Friday ? I like quick fix in general but this might be an exceptional case | 09:19 |
| opendevreview | Dr. Jens Harbott proposed openstack/openstackdocstheme master: Fix series selection and sorting https://review.opendev.org/c/openstack/openstackdocstheme/+/915128 | 12:41 |
| opendevreview | Dr. Jens Harbott proposed openstack/openstackdocstheme master: Don't offer to show unmaintained versions https://review.opendev.org/c/openstack/openstackdocstheme/+/915129 | 12:41 |
| opendevreview | Takashi Kajinami proposed openstack/oslo.log master: Disable implementation for watch_log_file https://review.opendev.org/c/openstack/oslo.log/+/915068 | 13:53 |
| hberaud | FYI, I'll absent during the next 2 weeks (PTO), I'll be back on Apr 22. See you soon. | 14:58 |
| *** hberaud is now known as hberaud_PTO | 15:00 | |
| opendevreview | Takashi Kajinami proposed openstack/oslo.log master: Disable implementation for watch_log_file https://review.opendev.org/c/openstack/oslo.log/+/915068 | 22:19 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!