[Kde-pim] Unannounced dependency bump?

[Harald Sitter]

On Wed, Jun 29, 2016 at 1:11 PM, Ben Cooksley <bcooksley at kde.org> wrote:
> On Wed, Jun 29, 2016 at 10:49 PM, Daniel Vrátil <dvratil at kde.org> wrote:
>> On Wednesday, June 29, 2016 12:24:10 PM CEST laurent Montel wrote:
>>> Le mercredi 29 juin 2016, 21:02:24 CEST Ben Cooksley a écrit :
>>> > Hi all,
>>> >
>>> > It would appear that PIM has bumped it's Grantlee dependency without
>>> > any announcement.
>>> >
>>> > Failing that, commits are missing from one or more of the PIM family
>>> > of repositories, the build metadata is out of date, or the CMake
>>> > infrastructure of the PIM repositories is insufficient to work within
>>> > the CI environment.
>>> >
>>> > Please see
>>> > https://build.kde.org/view/FAILED/job/messagelib%20master%20kf5-qt5/325/PL
>>> > A
>>> > TFORM=Linux,compiler=gcc/console
>>> >
>>> > Please correct this and provide an explanation for the issue.
>>>
>>> The problem is a grantleetheme problem. It was a bad commit.
>>> It's fixed.
>>
>> Note that GrantleeTheme is our internal library.
>>
>>>
>>> > PIM buildability continues to be an ongoing and major issue -
>>
>> Excluding honest mistakes like this one, our only issue is with build order
>> due to API changes across modules. If I break API in one module and push a fix
>> to another module that depends on the new API, it will break if it finishes
>> before the first one. If I wait with pushing the API adjustment in the other
>> module but someone else triggers the build anyway, we have the same problem.
>> We cannot prevent this easily unless the CI can ensure build order....
>
> Something we can't do

Well, not with that attitude we can't ;)

I'd do the following
- define new commit keyword ABI-BREAK
- Jenkins finds keyword in commits to integrate
- Jenkins blocks implicit downstreams (that is: downstreams as per
metadata dependency tree, not actual jenkins downstreams, although
that's also a possibility I suppose)
-- the actual nature of how this is achieved is what one would need to
look into. a possible option would be to create a temporary job that
is run in parallel but simply sleeps all the time and has the relevant
blockees as downstreams and the breaking job as upstream. when
upstream finishes it kills the temporary job thus unblocking all
downstreams.

If someone is interested in building a proof of concept of this,
getting your own jenkins for testing should be easy with a docker
image. And from there it's mostly playing with
downstream/upstream/blocking plugins to get to something that is
opt-in on a per-build basis but still reliable enough to prevent
failed builds due to ABI/API/compat changes in downstreams.

HS