On maandag 6 september 2021 14:21:00 CEST Christoph Cullmann
(cullmann.io) wrote:
> I would prefer to not have some optional category to be sure
> the CI always builds with the same state of dependencies, too.
A CI build would always build with the latest release (or
whatever the repo owner stat
On maandag 6 september 2021 11:48:39 CEST Ben Cooksley wrote:
> > Pushing everything into required is likely not scalable,
> > causing projects too wait too long for compile.
> > Avoiding the optional ones means you lack coverage of compile
> > and testing failures due to changes in libs.
>
> The
Hi Ben,
not sure on which priority it is regarding the KDE Frameworks but I've
added one on GCompris (
https://invent.kde.org/education/gcompris/-/commit/67c9839d7970b360b5d6b0ec928b492f9003d07d)
if it can help on more tests.
Cheers,
Johnny
Le dim. 5 sept. 2021 à 12:11, Ben Cooksley a écrit :
On Mon, Sep 6, 2021 at 9:00 PM Tom Zander wrote:
> On zondag 5 september 2021 08:13:09 CEST Ben Cooksley wrote:
> > In terms of the format of the 'Dependencies' section,
>
> Playing with kde-build script and noticing the fast growing
> dependency trees we have today, I think it may be beneficial
On zondag 5 september 2021 08:13:09 CEST Ben Cooksley wrote:
> In terms of the format of the 'Dependencies' section,
Playing with kde-build script and noticing the fast growing
dependency trees we have today, I think it may be beneficial to
have two types of compile dependencies in this setup.
How do we get a visual on exactly which lines are covered by auto testing
and which aren't?
