[Kde-games-devel] Merge frameworks in master

[Ian Wadham]

Hi Jeremy,

On 03/01/2015, at 2:10 AM, Jeremy Whiting wrote:
> Actually kdesrc-build is quite capable of handling this transition. I'll explain below.
> 
> On Fri, Jan 2, 2015 at 12:03 AM, Ian Wadham <iandw.au at gmail.com> wrote:
> Hi Jeremy,
> 
> On 01/01/2015, at 11:53 PM, Jeremy Whiting wrote:
> > On Wed, Dec 31, 2014 at 8:31 PM, Ian Wadham <iandw.au at gmail.com> wrote:
> >
> > Ian said: As far as I am aware, and I think I heard this from Albert on another list, there
> > will be no further releases from master --- KDE 4.14 was the last one.  Indeed,
> > if I understand correctly, the concept of "master" is obsolete in Frameworks/KF5
> > and releases are done from parallel repositories, e.g. Dr Konqi source code
> > exists in the kde/kde-runtime repository and also (temporarily, I am told) in
> > plasma-workspace repository on KF5.
> >
> > Jeremy: This is a misconception. Only "kdelibs" no longer has a master branch that
> > gets released. That is simply because it has been split into many smaller git repos
> > "the frameworks" which are released from master branch. All applications in
> > Applications releases come from their respective master branches.
> 
> Ah, OK, thanks.  I guess it was the two-repository setup for kde-runtime that
> had me confused.
> 
> > Yes, I believe Laurent means merging frameworks+master -> master. Also as he said you can continue to build kdelibs4 based applications with kdesrc-build, simply set:
> > branch-group latest-qt4
> > in your global options as documented in kdesrc-build/kdesrc-buildrc-sample which will use the latest qt4 based branch of all libraries and applications.
> 
> I am already using "branch-group latest-qt4", but the description in kdesrc-buildrc
> is "- latest-qt4 (the upcoming KDE 4 release)", which is obviously out-of-date… :-)
> The repository at
> https://projects.kde.org/projects/extragear/utils/kdesrc-build/repository/revisions/master/entry/kdesrc-buildrc-sample
> says the same about "branch-group latest-qt4".  What I get from it is a mixture of
> branches: KDE/4.14 for kdelibs and master for KDE Games, which I think is as it
> should be at the moment.  If Laurent merges the frameworks branches of KDE
> Games into the master branches, I doubt if kdesrc-build's "latest-qt4" will be
> able to spot the boundary-lines within the master branches.
> 
> kdesrc-build uses kde-build-metadata to know which branch of each project to build for the different configurations. I believe when laurent merges frameworks to master he'll update (or add) the branch information to kde-build-metadata so latest-qt4 will be Applications/14.12 instead of master for the applications he merges. We've done similarly in kdeedu with success.
>  
> 
> So maybe I should drop back to "- stable-qt4 (the last KDE 4 release, plus bugfixes)"
> for any downstream KDE Games work I may wish to do.  I am only on "latest-qt4" for
> the work I was doing on fixing kde-runtime/drkonqi.
> 
> If we decide to merge the ported games to master branches (you guys decide, not me I'm just a lurker) then I suggest you continue to use latest-qt4.
>  
> 
> > Ian said: BTW KSudoku and Kubrick depend on OpenGL and Qt's support for OpenGL
> > widgets, a requirement that is not so common in other KDE software, I believe.
> > I hope this will not present any problems re porting to Frameworks/KF5.
> >
> > Jeremy said: The porting has been done from what I see, the only question is which
> > version (qt4/kdelibs4 based or qt5/kf5 based) will be used for the upcoming spring release
> > (which will most likely be called Applications/15.04).
> 
> Laurent has ported 3 of the 5 games I maintain: KGoldrunner, KJumpingCube and Palapeli.
> 
> Of the other two, KSudoku has a frameworks branch, but from what I can see, there is essentially
> no new code there --- so the porting has not yet been done.  And Kubrick does not yet have a
> frameworks branch.  I am looking at https://projects.kde.org/projects/kde/kdegames/kubrick/repository.
> 
> Ah, I see. In this case I strongly suggest creating a wiki page similar to https://community.kde.org/KDEEdu/RouteToKF5 to track the progress of each game. This was very handy when preparing for the last release in kdeedu module. Laurent, would you create such a page with what you've done so far? That would help immensely to coordinate which games still need to be ported and who is working on said ports etc.
>  
> 
> > Ian, If it helps I can do some testing on linux of the frameworks branches before they are merged.
> 
> Thanks, Jeremy, that would be a great help.  I can contribute too, by eyeballing the changes,
> suggesting some stringent tests, providing desired results and helping with the debugging
> aids and messages, if we need them.
> 
> The top-level changes for KF5 should not be a huge problem.  My greatest worry is that something
> nasty will turn up in the internals of Qt 5.  It has happened before.  The KGoldrunner graphics, in
> particular, have had to be re-written 6 times in the 13 years since I first checked KGoldrunner in.
> 
> I also had to write a super-class for QTimer, because the Qt 4 version omits signals quite often.
> That is a feature, not a bug.  QTimer is not intended to be super-precise in real time.
> 
> BTW is Qt 5 still using raster graphics?  There is a bongle in libkdegames that makes it mandatory.
> 
> > I also like Albert's idea of having one day per application to test/debug these. We can blog
> > about it and get some community members to test one application each day on linux to check
> > for any regressions before merging the frameworks branches to master.
> 
> The key will be to get people who know how to play the games and are familiar with the
> various options, settings and flow of control (gameplay).
> 
> Yep, I can blog about it, I'm sure we have many community members that enjoy the various games and would be happy to test the latest version if we have:
> 1. Clear instructions for building/installing them
> 2. A coordinated page of what has been tested in each game that contributors can easily update (I suggest a wiki, low barrier to entry)

That is an excellent plan.  I am sending all of the above via the KDE Games list,
as I think you just sent it privately before.

Cheers, Ian W.