[Kde-pim] Unannounced dependency bump?

[Ben Cooksley]

On Thu, Jun 30, 2016 at 2:15 AM, Milian Wolff <mail at milianw.de> wrote:
> On Mittwoch, 29. Juni 2016 13:34:33 CEST Harald Sitter wrote:
>> 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/32
>> >>> > 5/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.
>
>
> This sounds awesome and we'd need that as well in KDevelop land.

What I meant was "something we can't do without writing custom plugins or code".
Anything is possible with custom stuff, given the time and effort to
implement it, and then maintain it as upstream (invariably) changes
things going forward.

Any volunteers?

Regards,
Ben

>
> Bye
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de
> _______________________________________________
> release-team mailing list
> release-team at kde.org
> https://mail.kde.org/mailman/listinfo/release-team
>