Re: Binary incompatible changes
On Tuesday 04 March 2014 12:08:07 Ben Cooksley wrote: On Sun, Mar 2, 2014 at 5:03 AM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 1 de març de 2014, a les 16:53:28, David Faure va escriure: On Saturday 01 March 2014 16:39:56 Albert Astals Cid wrote: Every time someone commits to okular, which may a bit too much, no? This is not what I suggested. I suggested: if A and B are both marked as dirty because a commit was just pushed to them, then look at whether one depends on the other, and rebuild in this order. If A isn't dirty, i.e. no commits for a long time, don't rebuild A. (where A is any okular dependency, in your example) Ah, agreed, that makes sense. Anyone knows if it's possible? This should be facilitated by the following Jenkins plugin. https://wiki.jenkins-ci.org/display/JENKINS/Build+Blocker+Plugin However that means that someone will need to reconfigure all jobs to include the dependency metadata - so we will probably want to script it I imagine. I'm a big fan of scripting (and I can write scripts for any change you'd like to see made to a bunch of files) -- but I thought you said jenkins jobs could not be modified in config files and had to be modified in the GUI? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Binary incompatible changes
On Tue, Mar 4, 2014 at 9:30 PM, David Faure fa...@kde.org wrote: On Tuesday 04 March 2014 12:08:07 Ben Cooksley wrote: On Sun, Mar 2, 2014 at 5:03 AM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 1 de març de 2014, a les 16:53:28, David Faure va escriure: On Saturday 01 March 2014 16:39:56 Albert Astals Cid wrote: Every time someone commits to okular, which may a bit too much, no? This is not what I suggested. I suggested: if A and B are both marked as dirty because a commit was just pushed to them, then look at whether one depends on the other, and rebuild in this order. If A isn't dirty, i.e. no commits for a long time, don't rebuild A. (where A is any okular dependency, in your example) Ah, agreed, that makes sense. Anyone knows if it's possible? This should be facilitated by the following Jenkins plugin. https://wiki.jenkins-ci.org/display/JENKINS/Build+Blocker+Plugin However that means that someone will need to reconfigure all jobs to include the dependency metadata - so we will probably want to script it I imagine. I'm a big fan of scripting (and I can write scripts for any change you'd like to see made to a bunch of files) -- but I thought you said jenkins jobs could not be modified in config files and had to be modified in the GUI? Jenkins has an Web API which can be used, as well as a Java client to help interact with it. In terms of modifying the configuration files on disk - they're XML based data, and i'm not sure if we can get Jenkins to reparse them short of restarting it completely. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Binary incompatible changes
El Dimarts, 4 de març de 2014, a les 21:34:12, Ben Cooksley va escriure: On Tue, Mar 4, 2014 at 9:30 PM, David Faure fa...@kde.org wrote: On Tuesday 04 March 2014 12:08:07 Ben Cooksley wrote: On Sun, Mar 2, 2014 at 5:03 AM, Albert Astals Cid aa...@kde.org wrote: El Dissabte, 1 de març de 2014, a les 16:53:28, David Faure va escriure: On Saturday 01 March 2014 16:39:56 Albert Astals Cid wrote: Every time someone commits to okular, which may a bit too much, no? This is not what I suggested. I suggested: if A and B are both marked as dirty because a commit was just pushed to them, then look at whether one depends on the other, and rebuild in this order. If A isn't dirty, i.e. no commits for a long time, don't rebuild A. (where A is any okular dependency, in your example) Ah, agreed, that makes sense. Anyone knows if it's possible? This should be facilitated by the following Jenkins plugin. https://wiki.jenkins-ci.org/display/JENKINS/Build+Blocker+Plugin However that means that someone will need to reconfigure all jobs to include the dependency metadata - so we will probably want to script it I imagine. I'm a big fan of scripting (and I can write scripts for any change you'd like to see made to a bunch of files) -- but I thought you said jenkins jobs could not be modified in config files and had to be modified in the GUI? Jenkins has an Web API which can be used, as well as a Java client to help interact with it. In terms of modifying the configuration files on disk - they're XML based data, and i'm not sure if we can get Jenkins to reparse them short of restarting it completely. You can just update the xml via the Java api with http://build.kde.org/cli/command/get-job and http://build.kde.org/cli/command/update-job Cheers, Albert -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Binary incompatible changes
On Friday 28 February 2014 20:49:34 Ben Cooksley wrote: I suggest that any further BC or SC changes be rolled out more carefully, with pushes being separated by sufficient time for the CI system to complete builds of earlier modules. I just tried to do that, with the KF5 version number increase, which also breaks if pushed to all modules at the same time. (since it changes both this is my version and this is the version I need in my dependencies). Here's my current solution - it starts nicely, with tier1 and then tier2 but then... (thanks Aurélien for the diagram, this would be impossible to do otherwise!) cd kdesupport/attica ; git push for f in `grep -l tier:\ 1 */*yaml`; do (cd `dirname $f` ; git push); done (wait for CI) for f in `grep -l tier:\ 2 */*yaml`; do (cd `dirname $f` ; git push); done (wait for CI) for d in kconfigwidgets kservice kpty kjsembed kunitconversion; do (cd $d ; git push) ; done (wait for CI) kiconthemes kdesu (wait for CI) ktextwidgets (wait for CI) kxmlgui (wait for CI) kcmutils kbookmarks (wait for CI) kio (wait for CI) kinit kparts kdeclarative knewstuff knotifyconfig kfileaudiopreview (wait for CI) kactivities kmediaplayer kross kdewebkit khtml (wait for CI) plasma-framework kdesignerplugin frameworkintegration kde4support (wait for CI) krunner (wait for CI) Done! So, in reality we have 12 tiers :-) So yeah, it's doable, but quite painful. I wish we could script this, but wait for CI is hard to script... But at least we could have tier 3.1, tier 3.2 etc. so we can push in layers with the layer information inside the repo instead of in this mail (or a hypothetical script that cannot really be automated). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Binary incompatible changes
On Saturday 01 March 2014 16:03:52 David Faure wrote: So yeah, it's doable, but quite painful. I wish we could script this, but wait for CI is hard to script... Oh, and if one doesn't have the rights for Build Now on build.kde.org, one cannot fix things after messing up the push order. Overall, the ideal solution would be if jenkins could notice that it needs to rebuild both A and B, and B depends on A (which it knows), so it needs to build A before B, rather than building B on top of an outdated A... -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Binary incompatible changes
El Dissabte, 1 de març de 2014, a les 16:06:24, David Faure va escriure: On Saturday 01 March 2014 16:03:52 David Faure wrote: So yeah, it's doable, but quite painful. I wish we could script this, but wait for CI is hard to script... Oh, and if one doesn't have the rights for Build Now on build.kde.org, one cannot fix things after messing up the push order. Overall, the ideal solution would be if jenkins could notice that it needs to rebuild both A and B, and B depends on A (which it knows), so it needs to build A before B, rather than building B on top of an outdated A... Right, but then if you need to build okular, you end up building polkit-qt-1 - Branch master kdegraphics-mobipocket - Branch master strigiutils - Branch master poppler - Branch master kactivities - Branch KDE/4.13 akonadi - Branch master automoc - Branch master plasma-mobile - Branch master grantlee - Branch master phonon - Branch master kdepimlibs - Branch master kdesupport-svn - Branch master kdelibs - Branch master qt - Branch 4.8 qca - Branch master libkexiv2 - Branch master soprano - Branch master libstreams - Branch master qjson - Branch master nepomuk-core - Branch master libdbusmenu-qt - Branch master strigidaemon - Branch master libstreamanalyzer - Branch master shared-desktop-ontologies - Branch master prison - Branch master strigiclient - Branch master cmake - Branch master attica - Branch qt4 kde-workspace - Branch KDE/4.11 Every time someone commits to okular, which may a bit too much, no? Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Binary incompatible changes
On Saturday 01 March 2014 16:39:56 Albert Astals Cid wrote: Every time someone commits to okular, which may a bit too much, no? This is not what I suggested. I suggested: if A and B are both marked as dirty because a commit was just pushed to them, then look at whether one depends on the other, and rebuild in this order. If A isn't dirty, i.e. no commits for a long time, don't rebuild A. (where A is any okular dependency, in your example) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE, in particular KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Binary incompatible changes
El Dissabte, 1 de març de 2014, a les 16:53:28, David Faure va escriure: On Saturday 01 March 2014 16:39:56 Albert Astals Cid wrote: Every time someone commits to okular, which may a bit too much, no? This is not what I suggested. I suggested: if A and B are both marked as dirty because a commit was just pushed to them, then look at whether one depends on the other, and rebuild in this order. If A isn't dirty, i.e. no commits for a long time, don't rebuild A. (where A is any okular dependency, in your example) Ah, agreed, that makes sense. Anyone knows if it's possible? Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Binary incompatible changes
Hi all, As there still seem to be remnants of the last BIC change to Frameworks around i've now commenced a force rebuild of all Frameworks on the CI system. Apologies in advance for any noise this creates - but it is necessary for this to be fixed to allow for other Frameworks dependent projects to use the CI system in a functional manner. I suggest that any further BC or SC changes be rolled out more carefully, with pushes being separated by sufficient time for the CI system to complete builds of earlier modules. Thanks, Ben ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
