[Libreoffice-qa] ESC meeting agenda - Adding topic: Broken release process when fresh become still and when still become EOL'ed

[Jan-Marek Glogowski]

Am 28.01.21 um 19:56 schrieb Timur Gadzo:
> I'm reading about rolling release idea, and I find it awful. It just 
> popped up, not sure why. Yes, it's more simple to publish, but it would 
> ruin LO usability.

ESC meeting minutes: 2020-12-10

https://lists.freedesktop.org/archives/libreoffice/2020-December/086428.html

I personally don't think it'll solve the problem. Feels a bit like gnupg 
or OpenSSL...

> LO is regression plagued product.

Yup. But honestly with the available resources, I don't see this 
changing in any time-frame, I can imagine. One IMHO main problem is, 
that we mainly have regression unit tests. So every change is almost 
guaranteed to break stuff. At least for me it feels like this. 
Everything is a lot of guesswork for me, even in areas, where people 
claim I'm the actual expert.

I remember patches, which had almost 100 iterations and still had a 
regression, literally a day after the commit.

Some of my stuff you might remember from QA too, like:
* The Scheduler rework, so we could get rid of crazy stuff, like the 1ms 
sleep, so Idles wouldn't starve each other or process stuff in the wrong 
sequence
* The "simplification" of the SalLayout to implement some little bit 
more understandable font handling, which broke the generic font cache, 
broke Windows font handling, slowing down documents in all aspects
* The unification of SolarMutex, which previously was simply ignoring 
underflows and "hope nothing breaks", which I stopped with std::abort() 
on underflow and still - now and then - get bisects on a crash to this 
change years later
* The whole "multi-threaded" GUI processing including now crazy stuff to 
redirect GUI stuff from non-GUI threads, like ignoring the mutex in the 
main thread to process GUI, while the original threads holds it.
* Or the stuff I broke while reworking the mail merge to work with 
complex documents and be usable with more the 100 document, not slowing 
down to a crawl with 200 (the sensible limit was at some point ~10k 
letter complexity docs)
* ... etc, etc, etc...

You may ask: do we have unit tests at least for some of the essential 
low level stuff I touched? Barely any and nothing I would consider 
remotely sufficient.

And this is just the major stuff I worked on an broke stuff for multiple 
releases.

And still currently there is 
https://gerrit.libreoffice.org/c/core/+/109829, which passed before XMas 
and now always aborts, with very broken logs indicating some (new?) 
Scheduler problem, I'm unable to reproduce locally, driving me nuts. And 
not taking into account the 12141 open bug reports against LibreOffice 
(according to the weekly bug summary of today).

So I can very much relate to your impression. But unless you have some 
large new resources available for the project, we'll have to bear with it.

ATB

Jan-Marek

P.S. and on top of it you have a lot of https://xkcd.com/1172/, simply 
because LO is around for a long time, used by many people and actually 
gets a lot more done, then I can imagine. I'm just remembering those 
blog post, where people replied how they use Draw for CAD...
P.P.S. x.y.6 is the most stable, but sometimes people actually want to 
use new features a bit earlier. Or they pay for commercial support.
P.P.P.S. And then there is also the very broken WASM port, which neither 
helps my sanity...