Re: [Libreoffice-qa] ESC meeting agenda: 2022-01-06 16:00 Berlin time

2022-01-05 Thread Jan-Marek Glogowski
I'm currently merging many gbuild changes, so I would like to see more 
variance in the Gerrit CI runs:


* CI infra change: switch a Gerrit build to --enable-mergelibs
+ was suggested by cloph to bring to ESC (see patch comments):
p1 https://gerrit.libreoffice.org/c/core/+/127426
   Switches Linux release 64 to --enable-mergelibs
+ We had a build-breaking patch for mergelibs / callgrind TB:
p2 https://gerrit.libreoffice.org/c/core/+/127394
p3 https://gerrit.libreoffice.org/c/core/+/127429
Not detectable by current Gerrit CI setup.
+ I tested p3 by pushing the patchset of p1 + p3.
- p1 broke the release build like the callgrind TB
- p3 fixed the broken mergelibs build
+ I suggest to switch a Gerrit build to mergelibs permanently
- = merge p1
- Will already fail in Gerrit, not later in Callgrind.
- I selected the Linux 64bit release, because it's the fastest
  x86, but I really have no preference.


Re: [Libreoffice-qa] A Query on a sudden increase in the bug dependency of LibreOffice

2021-04-26 Thread Jan-Marek Glogowski

Hi Hadi,

Am 26.04.21 um 21:16 schrieb Hadi Jahanshahi:

I have a question regarding bug dependency in LibreOffice.
While I was studying the blocking and blocked bugs, I found that in 
LibreOffice, after 2017, there is a sudden spike in the number of the 
found dependencies.


[snip]

May I ask what is the interpretation for that sudden increase? What 
happened that developers started to find these many bug dependencies?
Thank you for your help inĀ advance. I hope that I contacted the correct 
list.


People at libreoffice-qa@lists.freedesktop.org probably have more 
insight. My guess is the following bugzilla query:


https://bugs.documentfoundation.org/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=REOPENED_status=NEEDINFO=product%2Ccomponent%2Cshort_desc%2Cchangeddate%2Copendate=short_desc=status_whiteboard=0_id=1298870_format=advanced=substring=substring=meta%5D=meta%5D

LO QA and devs use "[META]" bugs to group bugs by affected "feature" 
areas blocking on the meta bug. As you can see in the query, we had 78 
before 2016 and 214 before 2017. Currently we have 834 meta bugs (885, 
if you include closed ones), so even with 12322 open bugs [1], it's much 
more likely a bug blocks on one of the meta bugs. If you filter these, I 
would guess your graph will almost flatline ~0.


HTH

[1] https://bugs.documentfoundation.org/page.cgi?id=weekly-bug-summary.html
___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: https://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/


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

2021-02-04 Thread 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...

___
List Name: Libreoffice-qa mailing list
Mail address: Libreoffice-qa@lists.freedesktop.org
Change settings: https://lists.freedesktop.org/mailman/listinfo/libreoffice-qa
Problems? http://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: http://wiki.documentfoundation.org/Netiquette
List archive: http://lists.freedesktop.org/archives/libreoffice-qa/