[Libreoffice-qa] ESC meeting agenda - Adding topic: Broken release process when fresh become still and when still become EOL'ed
glogow at fbihome.de
Thu Jan 28 21:03:18 UTC 2021
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
I personally don't think it'll solve the problem. Feels a bit like gnupg
> 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
* 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
And this is just the major stuff I worked on an broke stuff for multiple
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.
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...
More information about the Libreoffice-qa