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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice



[Index of Archives]     [LARTC]     [Bugtraq]     [Yosemite Forum]     [Photo]

  Powered by Linux