Re: Cleaning up check targets (was Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05)

[Thorsten Behrens]

Luboš Luňák wrote:
> Backwards compatibility. That includes Jenkins builds (all branches
> use the same setup, right?).
>
Perhaps a good idea then to introduce a CI driver scriptlet (or
target) into core?

I can imagine that might come in handy, given perhaps large-scale
rework of the build system ahead of us..

Cheers,

-- Thorsten


signature.asc
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Cleaning up check targets (was Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05)

[Stephan Bergmann]

On 17/03/2020 15:43, Luboš Luňák wrote:

On Tuesday 17 of March 2020, Stephan Bergmann wrote:

* Why merely deprecate slowcheck, instead of removing it completely?


  Backwards compatibility.


...after 
 
"change buildbot target to 'unitcheck slowcheck'", I see.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Cleaning up check targets (was Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05)

[Luboš Luňák]

On Tuesday 17 of March 2020, Stephan Bergmann wrote:
> On 17/03/2020 11:35, Luboš Luňák wrote:
> >   So, proposal: 'slowcheck' will be deprecated and will simply map
> > to 'unitcheck', and 'unitcheck' will be the target to get just the "fast"
> > checks. 'check' will map to 'unitcheck slowcheck subsequentcheck uicheck'
> > also in modules. That would be consistent and also mostly backwards
> > compatible (with the exception of 'make .check').
>
> * Why merely deprecate slowcheck, instead of removing it completely?

 Backwards compatibility. That includes Jenkins builds (all branches use the 
same setup, right?).

-- 
 Luboš Luňák
 l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: Cleaning up check targets (was Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05)

[Stephan Bergmann]

On 17/03/2020 11:35, Luboš Luňák wrote:

  So, proposal: 'slowcheck' will be deprecated and will simply map
to 'unitcheck', and 'unitcheck' will be the target to get just the "fast"
checks. 'check' will map to 'unitcheck slowcheck subsequentcheck uicheck'
also in modules. That would be consistent and also mostly backwards
compatible (with the exception of 'make .check').


* Why merely deprecate slowcheck, instead of removing it completely?

* A probably better description of unitcheck than running the "fast" 
checks is that it runs tests that do not depend on a fully populated 
instdir.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Cleaning up check targets (was Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05)

[Luboš Luňák]

On Thursday 05 of March 2020, Markus Mohrhard wrote:
> Hey,
>
> * Changing the default ‘make’ target (Lubos)
>
> >   + https://gerrit.libreoffice.org/c/core/+/89820
> >   + keeping ‘make check’ unchanged
> >   + plain ‘make’ would just build, not run tests
> >   + buildbot owners: need to run ‘make unitcheck slowcheck’ on
> > Windows/macOS, not just plain ‘make’ to avoid loosing test coverage
>
> Is there still a reason to have independent unitcheck and slowcheck
> targets? They are historically different because a default module level
> make would only execute the unitcheck and not the slowcheck target but if a
> module level make is not executing a unitcheck anymore, slowcheck can just
> be merged into unitcheck.

 I can do cleanup of check targets too, but can we first have a consensus on 
what the result of the cleanup actually should be? AFAICT the various check 
targets are an inconsistent mess too: In a module, 'make check' is equivalent 
to 'make unitcheck slowcheck'. But at the top level, 'make check' is 
equivalent to 'make unitcheck slowcheck subsequentcheck uicheck'.

 So, proposal: 'slowcheck' will be deprecated and will simply map 
to 'unitcheck', and 'unitcheck' will be the target to get just the "fast" 
checks. 'check' will map to 'unitcheck slowcheck subsequentcheck uicheck' 
also in modules. That would be consistent and also mostly backwards 
compatible (with the exception of 'make .check').

 Any comments or better ideas?

-- 
 Luboš Luňák
 l.lu...@collabora.com
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05

[Rene Engelhard]

Hi,

On Tue, Mar 10, 2020 at 04:21:26PM +0100, rene.engelh...@mailbox.org wrote:
> Probably because it depends on "build" which we probably patch out for 
> obvious reasons (we have the jars built and run against /usr/lib/libreoffice) 
> and thus if build doesn't run the test anymore just the java tests would be 
> built...

Argh. Nevermind. I guess see why it works for me and build only Java stuff.
(https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/tests/patches/java-subsequentcheck-standalone.diff#L77)

Nevertheless, we should allow *more* checks to run itself and against the
installed LO, not *less*.
And merging subsequentcheck into unitcheck would be less and make
unitcheck does a shitloads of tests which cannot be sanely ran against
a (system-wide) already installed LO. 

Regards,

Rene
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05

[rene . engelhard]

Am 10. März 2020 14:16:26 MEZ schrieb Stephan Bergmann :
>
>> make subsequentcheck does only run java tests: cf.
>https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/tests/junit.
>That one results in
>https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libreoffice/4506235/log.gz
>+search for the junit test.)
>
>At least for my local build, that's not the case:
>
>> $ make subsequentcheck
>[...]
>> [PYT] dbaccess_python
>> [JUT] forms_complex
>> [JUT] comphelper_complex
>> [CUT] io_textinputstream
>[...]

Probably because it depends on "build" which we probably patch out for obvious 
reasons (we have the jars built and run against /usr/lib/libreoffice) and thus 
if build doesn't run the test anymore just the java tests would be built...



>___
>LibreOffice mailing list
>LibreOffice@lists.freedesktop.org
>https://lists.freedesktop.org/mailman/listinfo/libreoffice


-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05

[Stephan Bergmann]

On 10/03/2020 11:02, Jan-Marek Glogowski wrote:

But honestly: why do we want to have subsequentcheck at all, and not
just run all tests after the build. This would get rid of all the
use_more_fonts and whatever over hacks currently exist. The machine
should be busy enough building LO. Eventually it might even lead to more
stable test runs ;-)


There are some honest unit tests around that have narrow, well-defined 
dependencies, and I think it's perfectly fine to keep them that way and 
have them run as soon as all their dependencies are available.  For some 
CompilerTests it even makes sense to run them as early as possible 
during the build, to verify that the assumptions of how the build will 
be conducted are met.


But yes, as I outlined before, we could get rid of subsequentcheck in 
the sense of having all *Tests lumped under one check target and have 
each *Test spell out its dependencies (as coarse or as fine grained as 
practical) individually.


(And then maybe have a machinery to add specific *Tests also to 
additional targets, like your javacheck target at 
 "Introduce javacheck 
target and move Java tests", or Rene's demand for running certain 
JUnitTests against a non-instdir installation.)


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05

[Stephan Bergmann]

On 10/03/2020 13:19, rene.engelh...@mailbox.org wrote:

Am 10. März 2020 10:25:50 MEZ schrieb Stephan Bergmann :

On 06/03/2020 16:31, Rene Engelhard wrote:

And i think https://gerrit.libreoffice.org/c/core/+/88833 should then

be

done, too, as it makes it more clear (what is a "subsequentcheck"?)

and

would be a good rationale to rename


https://packages.debian.org/search?keywords=libreoffice-subsequentcheckbase

to something sane (that one is used for in the autopkgtests which run
the junit tests against a installed (in /usr/lib/libreoffice) LO)


I'm not sure I understand you.  subsequentcheck is orthongonal to
JUnitTest.  There are JUnitTests that are not in subsequentcheck, and
there are tests other than JUnitTests that are in subsequentcheck.


The OOoRunner tests, yes. Otherwise: no.


No idea what you mean with "yes" and "no" there.


make subsequentcheck does only run java tests: cf. 
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/tests/junit.
 That one results in 
https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libreoffice/4506235/log.gz
 +search for the junit test.)


At least for my local build, that's not the case:


$ make subsequentcheck

[...]

[PYT] dbaccess_python
[JUT] forms_complex
[JUT] comphelper_complex
[CUT] io_textinputstream

[...]

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05

[Stephan Bergmann]

On 10/03/2020 10:47, Michael Stahl wrote:

On 10.03.20 10:25, Stephan Bergmann wrote:
After the transition from the two-stage dmake-based build system to 
gbuild was completed, this could have been cleaned up, moving the 
relevant dependencies into the individual tests. 


this was actually done for new tests and turned out to be a horrible 
idea leading to dozens of lines of copypasta in every CppunitTest 
makefile and still missing vital dependencies that then led to hours 
wasted debugging test failures that only happen sometimes when building 
from scratch.


Oh, what I meant with "relevant dependencies" there was rather the 
coarse dependencies that subsequentcheck itself currently depends on. 
(If I understand solenv/gbuild/Module.mk correctly, something like its



$(call gb_Module_get_subsequentcheck_target,$(1)) : $$(gb_Module_CURRENTTARGET)
$$(gb_Module_CURRENTTARGET) :| \
$(call gb_Postprocess_get_target,AllModulesButInstsetNative) \
$(call gb_Package_get_target,instsetoo_native_setup) \
$(call gb_Package_get_target,instsetoo_native_setup_ure)


and probably wrapped up as some convenience macro to be used in the 
individual tests' .mk files.)


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05

[rene . engelhard]

Am 10. März 2020 10:25:50 MEZ schrieb Stephan Bergmann :
>On 06/03/2020 16:31, Rene Engelhard wrote:
>> And i think https://gerrit.libreoffice.org/c/core/+/88833 should then
>be
>> done, too, as it makes it more clear (what is a "subsequentcheck"?)
>and
>> would be a good rationale to rename
>>
>https://packages.debian.org/search?keywords=libreoffice-subsequentcheckbase
>> to something sane (that one is used for in the autopkgtests which run
>> the junit tests against a installed (in /usr/lib/libreoffice) LO)
>
>I'm not sure I understand you.  subsequentcheck is orthongonal to 
>JUnitTest.  There are JUnitTests that are not in subsequentcheck, and 
>there are tests other than JUnitTests that are in subsequentcheck.

The OOoRunner tests, yes. Otherwise: no.

make subsequentcheck does only run java tests: cf. 
https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/tests/junit.
 That one results in 
https://ci.debian.net/data/autopkgtest/unstable/amd64/libr/libreoffice/4506235/log.gz
 +search for the junit test.)

>But then again, the distinction between unitcheck and subsequentcheck 
>continued to look somewhat useful, to have a default make target that 
>runs some but not all of the tests.  Now that that odd default make 
>target is going away, it should indeed become possible to drop the 
>distinction between unitcheck and subsequentcheck.)

Please not, as the unit tests can't be ran against an installed office as quite 
easy as the subsequentcheck tests 
(https://salsa.debian.org/libreoffice-team/libreoffice/libreoffice/-/blob/master/tests/patches/java-subsequentcheck-standalone.diff
 and the file mentioned above)

Regards

Rene


-- 
Diese Nachricht wurde von meinem Android-Gerät mit K-9 Mail gesendet.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05

[Jan-Marek Glogowski]

Am 10.03.20 um 10:47 schrieb Michael Stahl:
> On 10.03.20 10:25, Stephan Bergmann wrote:
>> After the transition from the two-stage dmake-based build system to
>> gbuild was completed, this could have been cleaned up, moving the
>> relevant dependencies into the individual tests. 
> 
> this was actually done for new tests and turned out to be a horrible
> idea leading to dozens of lines of copypasta in every CppunitTest
> makefile and still missing vital dependencies that then led to hours
> wasted debugging test failures that only happen sometimes when building
> from scratch.

I can imagine. There was also some more discussion in my linked
javacheck patch: https://gerrit.libreoffice.org/c/core/+/88833, which
should have been on the list.

But honestly: why do we want to have subsequentcheck at all, and not
just run all tests after the build. This would get rid of all the
use_more_fonts and whatever over hacks currently exist. The machine
should be busy enough building LO. Eventually it might even lead to more
stable test runs ;-)

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05

[Michael Stahl]

On 10.03.20 10:25, Stephan Bergmann wrote:
After the transition from the two-stage 
dmake-based build system to gbuild was completed, this could have been 
cleaned up, moving the relevant dependencies into the individual tests. 


this was actually done for new tests and turned out to be a horrible 
idea leading to dozens of lines of copypasta in every CppunitTest 
makefile and still missing vital dependencies that then led to hours 
wasted debugging test failures that only happen sometimes when building 
from scratch.


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05

[Stephan Bergmann]

On 06/03/2020 16:31, Rene Engelhard wrote:

And i think https://gerrit.libreoffice.org/c/core/+/88833 should then be
done, too, as it makes it more clear (what is a "subsequentcheck"?) and
would be a good rationale to rename
https://packages.debian.org/search?keywords=libreoffice-subsequentcheckbase
to something sane (that one is used for in the autopkgtests which run
the junit tests against a installed (in /usr/lib/libreoffice) LO)


I'm not sure I understand you.  subsequentcheck is orthongonal to 
JUnitTest.  There are JUnitTests that are not in subsequentcheck, and 
there are tests other than JUnitTests that are in subsequentcheck.


(For mostly historical reasons, the difference between unitcheck and 
subsequentcheck is that the latter depends on a fully populated instdir 
before running its tests.  After the transition from the two-stage 
dmake-based build system to gbuild was completed, this could have been 
cleaned up, moving the relevant dependencies into the individual tests. 
But then again, the distinction between unitcheck and subsequentcheck 
continued to look somewhat useful, to have a default make target that 
runs some but not all of the tests.  Now that that odd default make 
target is going away, it should indeed become possible to drop the 
distinction between unitcheck and subsequentcheck.)


___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05

[Rene Engelhard]

Hi,

On Fri, Mar 06, 2020 at 09:22:51AM +0100, Miklos Vajna wrote:
> On Fri, Mar 06, 2020 at 01:50:06AM +0800, Markus Mohrhard 
>  wrote:
> > Is there still a reason to have independent unitcheck and slowcheck
> > targets? They are historically different because a default module level
> > make would only execute the unitcheck and not the slowcheck target but if a
> > module level make is not executing a unitcheck anymore, slowcheck can just
> > be merged into unitcheck.
> 
> I think you're right, that could be simplified once the above change
> goes in.

And i think https://gerrit.libreoffice.org/c/core/+/88833 should then be
done, too, as it makes it more clear (what is a "subsequentcheck"?) and
would be a good rationale to rename
https://packages.debian.org/search?keywords=libreoffice-subsequentcheckbase
to something sane (that one is used for in the autopkgtests which run
the junit tests against a installed (in /usr/lib/libreoffice) LO)

Regards,

Rene
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05

[Miklos Vajna]

Hi Markus,

On Fri, Mar 06, 2020 at 01:50:06AM +0800, Markus Mohrhard 
 wrote:
> Is there still a reason to have independent unitcheck and slowcheck
> targets? They are historically different because a default module level
> make would only execute the unitcheck and not the slowcheck target but if a
> module level make is not executing a unitcheck anymore, slowcheck can just
> be merged into unitcheck.

I think you're right, that could be simplified once the above change
goes in.

Regards,

Miklos


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice-qa] ESC meeting minutes: 2020-03-05

[Markus Mohrhard]

Hey,

* Changing the default ‘make’ target (Lubos)
>   + https://gerrit.libreoffice.org/c/core/+/89820
>   + keeping ‘make check’ unchanged
>   + plain ‘make’ would just build, not run tests
>   + buildbot owners: need to run ‘make unitcheck slowcheck’ on
> Windows/macOS, not just plain ‘make’ to avoid loosing test coverage
>
>
Is there still a reason to have independent unitcheck and slowcheck
targets? They are historically different because a default module level
make would only execute the unitcheck and not the slowcheck target but if a
module level make is not executing a unitcheck anymore, slowcheck can just
be merged into unitcheck.

Markus
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice-qa] ESC meeting minutes: 2020-03-05

[Miklos Vajna]

* Present:
+ Eike, Thorsten, Heiko, Michael S, Gabriel, Ilmari, blendergeek, Michael 
W, Caolan, Olivier, Xisco, Miklos

* Completed Action Items:
   + Update VS baseline to 2019 in git (Stephan)
   + Install current VS2019 on build bots / Jenkins (Cloph, Thorsten)
   + Enable skia by default on master and Windows, replacing GL (Lubos)

* Pending Action Items:
   + Propose new certified developers (Kendy, Stephan, Thorsten)

* Release Engineering update (Xisco)
   + 7.0 status: feature freeze is last week of May
   + 6.4 status: 6.4.2 rc2 will be tagged next week
   + 6.3 status: 6.3.6 in April
   + Remotes
   + Android viewer: core.git java viewer is currently broken on master
 + both arch64 and x86 (crash on doc load, will investigate)
 + have 2 changes in gerrit attempting to fix these problems (Michael W)
   + Online

* Documentation (Olivier)
   + New Help
  + Some auxiliary XSLT for refactoring (ohallot)
  + refactor for readability of JS (buovjaga)
   + Helpcontents2
  + Fixes and updates for UI-HC2 better match (S. Chaiklin, M. Kaganski)
  + Some refactoring of pages (buovjaga)
  + Fixes on contents/liguistics (fitoshido, S. Schröder)
   + Guides
  + Works in progress for all guides.
  + some investigation for managing translations of Guides (WIP) (ohallot)


* UX Update (Heiko)
   + Bugzilla (topicUI) statistics
   238(238) (topicUI) bugs open, 260(260) (needsUXEval) needs to be 
evaluated by the UXteam
   + Updates:
   BZ changes   1 week1 month3 months   12 months
added  6(-4) 23(-2) 47(-3) 118(-2)
commented 79(-40)   379(-14)   994(-40)   2933(25)
  removed  1(1)   3(1)   8(0)   18(0)
 resolved 11(-10)48(3) 103(-3) 269(2)
   + top 10 contributors:
 Heiko Tietze made 284 changes in 1 month, and 1484 changes in 1 year
 Foote, V Stuart made 75 changes in 1 month, and 530 changes in 1 year
 Dieter Praas made 70 changes in 1 month, and 429 changes in 1 year
 Roman Kuznetsov made 49 changes in 1 month, and 337 changes in 1 year
 Seth Chaiklin made 48 changes in 1 month, and 168 changes in 1 year
 Xisco Faulí made 28 changes in 1 month, and 447 changes in 1 year
 Kainz, Andreas made 27 changes in 1 month, and 286 changes in 1 year
 锁琨珑 made 27 changes in 1 month, and 34 changes in 1 year
 Timur made 18 changes in 1 month, and 146 changes in 1 year
 Cor Nouws made 17 changes in 1 month, and 175 changes in 1 year

+ New tickets with needsUXEval Feb/27-Mar/05

   * UNO command to dock all toolbars
 + https://bugs.documentfoundation.org/show_bug.cgi?id=131005
   => WF
   * Navigate document content when selection is made in the Navigator
 + https://bugs.documentfoundation.org/show_bug.cgi?id=131063
   => many pro and con

   * Remove "rename" option for hatch context menu and add "delete" to
 dialog box
 + https://bugs.documentfoundation.org/show_bug.cgi?id=131036
   * What is the difference between a "Styles deck" and a "Styles window"?
 + https://bugs.documentfoundation.org/show_bug.cgi?id=131078
   => forwarded to documentation

   * UI: Find All search result frame cannot resized
 + https://bugs.documentfoundation.org/show_bug.cgi?id=131047
   => NEEDINFO

   * Writer table: "Number Format..." removed from context menu
 + https://bugs.documentfoundation.org/show_bug.cgi?id=131046
   => unconfirmed

+ Some input for the branding of the upcoming release
   + https://bugs.documentfoundation.org/show_bug.cgi?id=130778
   + cool proposals

* Crash Testing (Caolan)
   + 1(+0) import failure, 2(+0) export failures
 - mini-run, normal run blocked due to problematic HW
   + 2 coverity issues
   + 11 ossfuzz issues
   + Mozilla added a hunspell fuzzer to oss-fuzz
 + may also help with fixing the problems

* Crash Reporting (Xisco)
    + https://crashreport.libreoffice.org/stats/version/6.3.4.2
    + (+221) 3050 2829 2188 3301 3769 3222 2057 984 0
    + https://crashreport.libreoffice.org/stats/version/6.3.5.2
    + (+323) 635 312 0
    + https://crashreport.libreoffice.org/stats/version/6.4.0.3
    + (-692) 8772 9464 6774 4842 419 0
    + https://crashreport.libreoffice.org/stats/version/6.4.1.2
    + (+2052) 2052 0

   + looks better than 6.4.0
 + we again only get the dynamic lib signatures
 + not sure if we need to just wait or something else is broken
   + will poke Cloph next week

* GSoC 2020 (Ilmari)
   + 
https://opensource.googleblog.com/2019/12/announcing-google-summer-of-code-2020.html
   + https://wiki.documentfoundation.org/Development/GSoC/Ideas
 + if you have the time, please do mentoring!
   + Student Application Period March 16 - 31, 2020
   + Application Review Period March 31, 2020 - April 27, 2020