Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: unbreaking LibreOffices tests on at least release architectures
0 views
Skip to first unread message
Jan Engelhardt
Jun 18, 2023, 9:10:04 PM6/18/23
to
On Sunday 2023-06-18 23:37, Rob Landley wrote:
>On 6/18/23 14:58, Rene Engelhard wrote:
>>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and
>>> the AGPL have been rejected soundly by most developers" and talked about how he
>>> regretted the move and the damage it had done to the project,
>>> https://archive.org/details/copyleftconf2020-allison
>>
>> Can we please talk about the actual issue at and - that is not the license.
>
>The issue is the number of developers engaging with this package have declined
>to the point problems have gone unnoticed and unfixed for a long time.
That may be a general problem not specific to Libreoffice, or any
one particular project.
As software grows to accomodate more features, it reaches a size
where it is "good enough" for users that they no longer feel a need
to invest time anymore as their needs are already satisfied, while at
the same time, it has become so large for others to not want to touch
it anymore.
Chromium sucks to touch. On the other hand, the Linux kernel has
evermore developers each round, and Linux distros have more packages
than ever before. So not all seems to be bad? Modularization seems
key, and that may just be what separates projects.
>On 6/18/23 14:58, Rene Engelhard wrote:
>>> Three years ago Samba maintainer Jeremy Allison lamented that "Both GPLv3 and
>>> the AGPL have been rejected soundly by most developers" and talked about how he
>>> regretted the move and the damage it had done to the project,
>>> https://archive.org/details/copyleftconf2020-allison
>>
>> Can we please talk about the actual issue at and - that is not the license.
>
>The issue is the number of developers engaging with this package have declined
>to the point problems have gone unnoticed and unfixed for a long time.
That may be a general problem not specific to Libreoffice, or any
one particular project.
As software grows to accomodate more features, it reaches a size
where it is "good enough" for users that they no longer feel a need
to invest time anymore as their needs are already satisfied, while at
the same time, it has become so large for others to not want to touch
it anymore.
Chromium sucks to touch. On the other hand, the Linux kernel has
evermore developers each round, and Linux distros have more packages
than ever before. So not all seems to be bad? Modularization seems
key, and that may just be what separates projects.
Adrian Bunk
Jun 19, 2023, 7:50:03 PM6/19/23
to
On Mon, Jun 19, 2023 at 11:29:34PM +0200, Rene Engelhard wrote:
>...
> Am 19.06.23 um 23:19 schrieb Adrian Bunk:
>...
> > For such a complex package I would expect 32bit breakage in every
> > release if upstream no longer tests on 32bit.
> Indeed, though at least for 32bit *build* issues they keep fixing them if I
> report them.
> > The pragmatic option would be to run only a smoketest for build success
> > on architectures not tested by upstream.
>
> And have Format->Character in Impress crash with Bus error like on mipsel?
> That doesn't sound too good for basic quality.
>
> There is a "smoketest" but it does just basic start. open, close stuff. Not
> even basic usage.
Let's be realistic regarding the available options, because the one you
want is not available.
You want every !a*64 architecture to have a porter spending time on
fixing libreoffice.
And thinking this through, since regressions in new upstream versions
are expected to be frequent you want new upstream versions of libreoffice
blocked from testing migration by any regression on one architecture
until a porter for this architecture has fixed the regression.
A new architecture like riscv64 might have enough porters for fixing
issues once or for some limited duration. That's it.
For each architecture you have the options:
1. declare libreoffice good enough on this architecture, or
2. don't build libreoffice on this architecture
There is no third option that architectures will provide porters fixing
your package all the time.
There are several other packages of comparable complexity, size and
testsuite (e.g. mozjs* or rustc). For a successful build they are using
either just a smoketest, or a maximum number of tolerable testsuite
failures.
> Regards,
>
> Rene
cu
Adrian
>...
> Am 19.06.23 um 23:19 schrieb Adrian Bunk:
>...
> > For such a complex package I would expect 32bit breakage in every
> > release if upstream no longer tests on 32bit.
> Indeed, though at least for 32bit *build* issues they keep fixing them if I
> report them.
> > The pragmatic option would be to run only a smoketest for build success
> > on architectures not tested by upstream.
>
> And have Format->Character in Impress crash with Bus error like on mipsel?
> That doesn't sound too good for basic quality.
>
> There is a "smoketest" but it does just basic start. open, close stuff. Not
> even basic usage.
Let's be realistic regarding the available options, because the one you
want is not available.
You want every !a*64 architecture to have a porter spending time on
fixing libreoffice.
And thinking this through, since regressions in new upstream versions
are expected to be frequent you want new upstream versions of libreoffice
blocked from testing migration by any regression on one architecture
until a porter for this architecture has fixed the regression.
A new architecture like riscv64 might have enough porters for fixing
issues once or for some limited duration. That's it.
For each architecture you have the options:
1. declare libreoffice good enough on this architecture, or
2. don't build libreoffice on this architecture
There is no third option that architectures will provide porters fixing
your package all the time.
There are several other packages of comparable complexity, size and
testsuite (e.g. mozjs* or rustc). For a successful build they are using
either just a smoketest, or a maximum number of tolerable testsuite
failures.
> Regards,
>
> Rene
cu
Adrian
Andreas Schwab
Jul 22, 2023, 8:30:04 AM7/22/23
to
On Jun 18 2023, Rene Engelhard wrote:
> For riscv64 I already pointed that out in the thread starting at
> https://lists.debian.org/debian-riscv/2023/06/msg00000.html, but for the
> other architectures there is the mail now. riscv64 is different because
> the failures are even more big than any other down below and it's actually
> a new architecture anyway.
Libreoffice is actually basically working on riscv64. I have tested it
with openSUSE Tumbleweed on BeagleV Beta and Hifive Unmatched (with an
AMD graphics card).
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
> For riscv64 I already pointed that out in the thread starting at
> https://lists.debian.org/debian-riscv/2023/06/msg00000.html, but for the
> other architectures there is the mail now. riscv64 is different because
> the failures are even more big than any other down below and it's actually
> a new architecture anyway.
Libreoffice is actually basically working on riscv64. I have tested it
with openSUSE Tumbleweed on BeagleV Beta and Hifive Unmatched (with an
AMD graphics card).
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
0 new messages