[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: Merge stable to master vs cherry-picking
From: Ben Cooksley <bcooksley () kde ! org>
Date: 2021-12-09 10:08:01
Message-ID: CA+XidOEexVwLxOqCi_XCAaeiJJ-hBGnT2EB4fApG8z=0bmVF4Q () mail ! gmail ! com
[Download RAW message or body]
On Wed, Dec 8, 2021 at 10:38 PM Friedrich W. H. Kossebau <kossebau@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
[Attachment #3 (text/html)]
<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Dec \
8, 2021 at 10:38 PM Friedrich W. H. Kossebau <<a \
href="mailto:kossebau@kde.org">kossebau@kde.org</a>> wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex">Am Mittwoch, 8. Dezember 2021, 07:44:32 CET \
schrieb Ben Cooksley:<br> > This is why I have been pushing for people to use \
@stable in their<br> > .kde-ci.yml files - even for the 'master' \
branch.<br> > It is much simpler for people if you can use stable/released \
dependencies<br> > when conducting development.<br>
<br>
Other than developers the CI though has no issues building all the deps from <br>
the master branches, right? So I wonder about the relationship here. \
<br></blockquote><div><br></div><div>The relationship is that developers may \
accidentally end up using new API or other functionality that only exists in current \
master.</div><div>That prevents people from using distribution packagers to develop \
on our software, and increases the barrier to entry.</div><div><br></div><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
And actually I see a harm if CI does not build master branches against master <br>
branches of libraries. If there is no testing of new API in the libraries (and <br>
this means, libraries beyond KF) against consuming products any issues in new <br>
API added to the libraries might be discovered too late.<br></blockquote></div><div \
class="gmail_quote"><br></div><div class="gmail_quote">The CI system is limited to \
testing two things:</div><div class="gmail_quote">1) That it compiles and installs \
successfully</div><div class="gmail_quote">2) That the tests execute \
successfully</div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div \
class="gmail_quote">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.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">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.</div><div \
class="gmail_quote">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.</div><div \
class="gmail_quote"><br></div><div class="gmail_quote"><br><blockquote \
class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid \
rgb(204,204,204);padding-left:1ex"> <br>
If we had endless resources, any product would be built on CI against a set of <br>
variants of the dependencies, starting with the minimal reuqired versions of <br>
libraries and then with the latest versions, and then some sensible <br>
combinations representing what is typical scenario in the real world.<br>
On our CI we only test one variant (per platform). And if we test master <br>
against master, this tests both the product and the dependency for <br>
integration.<br>
If we only test master against stable, then the stable of the dependency will <br>
get tested twice here (as stable against stable also tests the same), but <br>
nothing will test master. And given master usually sees more changes, it <br>
should get at least the same coverage.<br>
<br>
So please rethink this. Or is there another requirement why the version of a <br>
dependency developers use locally needs to be the same version as used on \
CI?<br></blockquote><div><br></div><div>What developers use is of little concern to \
the CI system.</div><div><br></div><div>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.</div><div>I would like to see that \
improved, to ensure we do not accidentally introduce barriers to entry that should \
not exist.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px \
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"> <br>
E.g. with KDevelop master, the find_package(LibKompareDiff2 5.0 CONFIG) means <br>
any version of LibKompareDiff2 from 5.0 to latest should be fine. Developers <br>
at home can use 5.0, CI can use latest master.<br></blockquote><div><br></div><div>CI \
should be using 5.0 - otherwise nobody is checking that newcomers can use \
5.0.</div><div>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.<br></div><div> \
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px \
solid rgb(204,204,204);padding-left:1ex"> <br>
Cheers<br>
Friedrich<br>
<br></blockquote><div><br></div><div>Cheers,</div><div>Ben</div><div><br></div></div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic