Merge stable to master vs cherry-picking

[Friedrich W. H. Kossebau]

Am Donnerstag, 9. Dezember 2021, 11:08:01 CET schrieb 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.

Those are accidents after all, and may rather be a chance to do a first 
contribution for newcomers.

More, @stable means latest-stable rather, not the minimum required versions. 
So this only catches usage of master API, not usages of API only in latest-
stable. And thus still be a hurdle for everyone not on latest-stable.

I guess we have no numbers here, even more as newcomers might give up 
silently. Yet I am not aware of mass accidents using master-only API. So I 
would not give that much weight to this argument myself.

> > 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.

When working on a library, which by nature is intended to be used by as many 
other software as possible, I think it cannot be expected that the developer 
also tests all those library consumers at the same time, even more their 
master/development versions (and thus also needing to have all the deps). 

Usually you only test those consumers for which you add new stuff to the 
library. For testing that there are no side-effects of those changes 
elsewhere, the integration of the development version of the library with the 
development version of all consumers needs to be automated rather, at least 
when it comes to building and automated tests. And that is what build.kde.org 
so far served well for, by building master against master.

Cheers
Friedrich