[Kde-games-devel] KMahjongg frameworks branch

[Frederik Schwarzer]

Hi,

I just realised that the 15.12 release cycle is coming to an end soon 
and the freeze has already happened.
So plan for KMahjongg frameworks branch would be to merge it right 
after the 15.12 branch has been created (december 9th ...). and then 
go through those old bug reports and close the ones that are already 
fixed by the qgraphic branch.

For me it looks quite good and I did not see problems introduced in 
frameworks branch so far.

Regards,
Frederik

Am Donnerstag, 26. November 2015, 13:08:26 schrieb Ian Wadham:
> On 26/11/2015, at 1:52 AM, Frederik Schwarzer wrote:
> > Am Dienstag, 24. November 2015, 16:28:06 schrieb Ian Wadham:
> > 
> > Hi Ian,
> > 
> >> I think, to keep matters simple, I will replace loadSettings() on
> >> the qgraphic branch with the entire method from the frameworks
> >> branch and commit it as a consolidated change.
> > 
> > Preferably the qgraphic branch should be put to sleep and further
> > porting work should go to frameworks branch directly.
> > But you had problems with KF5, right?
> 
> Yes, I can only compile, build and run the qgraphic branch, so I
> will use it to investigate any problems you may report, but I will
> keep it local only.  I did have in mind to push fixes centrally,
> like the one for the recursion problem, so that you could
> cherry-pick them.  But I now think it will be easier if I send a
> patch.  You can then eyeball it, before committing and perhaps
> getting conflicts.
> 
> >> I could cherry-pick changes from frameworks into qgraphic, but my
> >> git skills are not good and I would be worried about making a
> >> mistake.
> > 
> > Yep, same here. I usually merge branches but then have problems
> > with understanding, which piece of code has been
> > added/changed/removed for what reason. I never cherry-picked.
> 
> Well, merging is safer, especially if there could be changes (e.g.
> scripty) that you are not aware of…  That way, you do not
> accidentally omit a change.
> >> The code really is getting to be a rat's nest, what with all the
> >> negatives. It might be cleaner to pre-define a boolean or two,
> >> with
> >> nice readable names, then have simpler if() statements.  OTOH,
> >> "if
> >> it ain't broke don't fix it".
> > 
> > And now to defining "broke". ;)
> 
> Self-defining… :-)  The correct English is "If it is not broken, do
> not fix it" or "If it isn't broken, don't fix it".  "Ain't" and
> "broke" are both "broken"… :-)
> 
> In olden days, "ain't" was a contraction of "am not", but it is
> still used in some local dialects… :-)
> 
> More seriously, "broke" (in my book) does not include stylistic
> problems, however much a nuisance they are for programmers and
> maintainers. "Ain't broke" means that the USER cannot see any
> problem and "don't fix it" means that you risk introducing problems
> which the user CAN see.
> > I just put the layout's name in the window's title bar in
> > frameworks branch.
> 
> Great. Thanks.  I have cherry-picked it… :-)
> 
> > For bigger non-bugfix changes I would like to wait until the
> > frameworks branch has been merged to master.
> 
> I agree, but I will not be able to make any changes to games that
> have been fully ported to Frameworks --- not for several months,
> maybe not for a year or more, maybe never (I am not getting any
> younger)… :-)
> 
> René Bertin has just started posting review items for porting
> Frameworks libraries and utilities to an Apple OS X environment
> (MacPorts).  He is working alone and has a long way to go.  But (at
> long last) KDE core developers are providing a little help.  Maybe
> that will snowball… :-)
> 
> Cheers, Ian W.
> 
> _______________________________________________
> kde-games-devel mailing list
> kde-games-devel at kde.org
> https://mail.kde.org/mailman/listinfo/kde-games-devel