[Kde-pim] Unannounced dependency bump?

[Milian Wolff]

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.

Bye
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/release-team/attachments/20160629/30f6e149/attachment.sig>