[Kde-games-devel] Merge frameworks in master

[Jeremy Whiting]

On Fri, Jan 2, 2015 at 11:32 PM, Ian Wadham <iandw.au at gmail.com> wrote:

> 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.
>
>
Doh, my bad.

At any rate, Laurent, can you create said wiki page of which games have
been ported, and which are in progress, and which need someone to start
them, etc? If you do that I'll blog/send an e-mail get people (maybe just
me, we'll see) to test the games that have been merged to master branch.

thanks,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-games-devel/attachments/20150103/9b5a9541/attachment.html>