WEBVTT

00:00.000 --> 00:13.800
Okay, so let's start this, okay, I'm going again and the next talk is going to be not

00:13.800 --> 00:22.000
something I achieved, it's mostly something like I want to ask the community and most

00:22.000 --> 00:31.680
specifically the ESC in the longer run, so I was looking at the source code of Libra

00:31.680 --> 00:43.680
Office and looks like there are some sort of stable API called URE and there are lots of methods

00:43.680 --> 00:58.560
and such marked as deprecated since some time but then how many are there and since

00:58.560 --> 01:07.840
when are those methods marked as deprecated because I saw a lot of them and that's somewhat

01:07.840 --> 01:11.840
of a fuzzy definition.

01:11.840 --> 01:21.200
So I started to do a little bit of githraping and a little bit of gith blaming to find out

01:21.200 --> 01:33.640
when were those deprecated marks added into the include slash and those directories.

01:33.640 --> 01:39.640
For now I have a data only for this part of the code base but also we have similar

01:39.640 --> 01:55.360
situation with the of API directory which is like this 1o API.

01:55.360 --> 02:07.440
So results are following there were 197 files in total in those directories of those 42

02:07.440 --> 02:21.040
content, some deprecated marks and in total there were 135 hits for this in the gith.

02:21.360 --> 02:31.360
More interesting part is since when are those in the code base and as you can see in the green

02:31.360 --> 02:43.200
part of the chart close to half of these are since open office all times which is kind of long time

02:44.080 --> 02:54.640
but even then since 2019 so 5 years there are only a very small percentage like

02:55.760 --> 03:03.200
less than 5, less at least 5 or even 10 years old deprecation.

03:03.440 --> 03:14.480
I would like to ask if this is really how it should go is this okay maybe it is maybe there are

03:14.480 --> 03:24.240
some reasons why we cannot throw out the threshold and I realize this is the bottom part of the

03:24.240 --> 03:31.840
priority list because who cares we have more problems which are actually visible to customer

03:33.280 --> 03:40.480
but also if you read the API documentation and you read oh this is deprecated deprecated

03:41.360 --> 03:51.040
why the fuck I read this sorry my UA might just cannot understand why is this even there

03:52.320 --> 03:59.680
are we serious about this deprecation or maybe it's just a joke I don't know

04:00.080 --> 04:12.400
yeah also there are some files which are completely unused according to some unused header

04:14.000 --> 04:24.000
finder script in the binary directory so this is complete trash but we still ship it

04:24.880 --> 04:36.800
yeah so this is already conclusions but what I see is we don't have any serious policy to

04:37.840 --> 04:46.880
eventually approach this like after 5 years 10 years whatever just sometime and there is no

04:46.880 --> 04:56.160
conscious effort to reuse the use of these APIs in the code base like I found one bug which was

04:56.160 --> 05:05.520
also very old which aimed to remove some of these old functionality from the code rest is just

05:06.240 --> 05:12.560
still there maybe some someone will replace it with better code maybe not

05:13.520 --> 05:29.760
yeah that's all the results so far I have shared the nice spreadsheet that I used for this

05:30.800 --> 05:41.360
talk in the next let's go then the slides are in the in the frozen system already uploaded and

05:41.360 --> 05:43.360
thank you