Merge stable to master vs cherry-picking

[Ben Cooksley]

On Wed, Dec 8, 2021 at 10:38 PM Friedrich W. H. Kossebau <kossebau at kde.org>
wrote:

> Am Mittwoch, 8. Dezember 2021, 07:44:32 CET schrieb Ben Cooksley:
> > This is why I have been pushing for people to use @stable in their
> > .kde-ci.yml files - even for the 'master' branch.
> > It is much simpler for people if you can use stable/released dependencies
> > when conducting development.
>
> Other than developers the CI though has no issues building all the deps
> from
> the master branches, right? So I wonder about the relationship here.
>

The relationship is that developers may accidentally end up using new API
or other functionality that only exists in current master.
That prevents people from using distribution packagers to develop on our
software, and increases the barrier to entry.


> And actually I see a harm if CI does not build master branches against
> master
> branches of libraries. If there is no testing of new API in the libraries
> (and
> this means, libraries beyond KF) against consuming products any issues in
> new
> API added to the libraries might be discovered too late.
>

The CI system is limited to testing two things:
1) That it compiles and installs successfully
2) That the tests execute successfully

While good things, they are no substitute for the software being run by a
developer and actually tested. That requires developers that run master for
everything.
There is already a number that do that - however it shouldn't stop
newcomers from being able to develop using stable if that is reasonable to
do so.

With regards to things within the same release unit, those should be using
@same not @stable - so those can still use the "latest" API where needed.
The barrier to entry for those however (except for areas like PIM that have
a colossal dependency tree) should be relatively small - usually just one
or two other projects that need to be built.



> If we had endless resources, any product would be built on CI against a
> set of
> variants of the dependencies, starting with the minimal reuqired versions
> of
> libraries and then with the latest versions, and then some sensible
> combinations representing what is typical scenario in the real world.
> On our CI we only test one variant (per platform). And if we test master
> against master, this tests both the product and the dependency for
> integration.
> If we only test master against stable, then the stable of the dependency
> will
> get tested twice here (as stable against stable also tests the same), but
> nothing will test master. And given master usually sees more changes, it
> should get at least the same coverage.
>
> So please rethink this. Or is there another requirement why the version of
> a
> dependency developers use locally needs to be the same version as used on
> CI?
>

What developers use is of little concern to the CI system.

The CI system however keeps watch over the buildability of our software,
and currently when it comes to testing whether minimum versions work does a
very minimal job of doing so.
I would like to see that improved, to ensure we do not accidentally
introduce barriers to entry that should not exist.


> E.g. with KDevelop master, the find_package(LibKompareDiff2 5.0 CONFIG)
> means
> any version of LibKompareDiff2 from 5.0 to latest should be fine.
> Developers
> at home can use 5.0, CI can use latest master.
>

CI should be using 5.0 - otherwise nobody is checking that newcomers can
use 5.0.
Experience has shown that maintainers/day to day developers do use master
and then go ahead and add dependencies on versions that are newer without
realising it - until someone comes along with a build that fails mid way
through because the version of $kdeLibrary they have is actually too old.


>
> Cheers
> Friedrich
>
>
Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20211209/b800e5b6/attachment.htm>