[09:04:13] <it-s> Good Morning/Day/Evening everyone
[09:04:22] <xMDKx> hello everyone
[09:04:23] <it-s> and welcome to our meeting
[09:04:34] <it-s> we are now starting
[09:05:22] <it-s> and the reason we have assembled (with ASM) you all today is to discuss a very important topic for our module
[09:05:34] <it-s> it's immense SIZE!
[09:05:49] <it-s> we are getting to large
[09:06:04] <it-s> the big question is - what do we od?
[09:06:08] <it-s> the big question is - what do we DO?
[09:06:40] <it-s> the suggestions thus far include:
[09:06:59] <it-s> a) KDEGames does no long accept new games for inclusion
[09:07:19] <it-s> b) the module is split into main and extra-gear
[09:07:53] <it-s> c) the games without an immediate maintainer are moved to playground, and replaced with new ones
[09:08:13] <it-s> lets discuss now
[09:08:14] <icwiener> Umm, first question from me (just for the record): How has "too big" been measured?
[09:08:15] <josef|bomba> it-s: With size, do you refer to just the number of games or the collective size of the games in bytes?
[09:08:35] <piacentini> Sorry fo jumping in, but we discussed this in Akademy 2008, no? The conclusion was that we should not bother with defining the structure (main/extragear)
[09:08:45] <wolfgang61> what are the practical problems with the size? For developers or for users?
[09:08:46] <piacentini> As distros
[09:08:50] <piacentini> are free to do so
[09:09:10] <xMDKx> it-s: why "large size" is a bad thing to kdegames?
[09:09:24] <Parkotron> The primary problem is that it's too big to maintain with our current number of active developers.
[09:09:32] <piacentini> One problem is lack of maintainers, I see. But this is unrelated to how many games we have
[09:09:39] <dimsuz_> problems are: games go in, maintainers dissapear, games are left unmaintained. and at this point even more games appear which want to be the part of the module
[09:09:59] <Parkotron> Since, 4.0 we've admitted a lot of new games, but many of those are practically unmaintained already.
[09:10:03] <piacentini> But preventing people from working on new games will not make them work on the unmaintained ones
[09:10:14] <scherfa> I think we are loosing quality if there are too much games inside the kde cycle
[09:10:16] <piacentini> So two separate issues
[09:10:35] <xMDKx> hum, maybe option "b" can be a good decision
[09:10:56] <scherfa> i prefer "c" and a wide discussion which game to add
[09:10:57] <piacentini> xMDKx: people did not accept that when we tried to classify games
[09:11:05] <mikelima> hi all, I'm late, sorry
[09:11:07] <piacentini> it-s tried it already
[09:11:12] <cvandonderen> doe sunmaintained here mean: 1) there are bugs that are not fixed or 2) there are no new features added to the games?
[09:11:15] <xMDKx> piacentini, well, you're right
[09:11:38] <icwiener> What would splitting to extragear change?
[09:11:42] <Parkotron> cvandonderen: That's a very tricky question.
[09:11:56] <piacentini> icwiener; extragear is not released with KDE
[09:11:59] <piacentini> so different cycles
[09:12:03] <icwiener> piacentini: It can be.
[09:12:08] <xMDKx> but if a game has no maintainer, who will complain? maybe the users...
[09:12:09] <icwiener> piacentini: If you ask for it.
[09:12:13] <piacentini> it can, but not locked to the same schedule
[09:12:21] <it-s> cvandonderen: no, it means - the original creator had left, and is no longer interested. and we now have to charge one of our own active devs to maintain it
[09:12:49] <cvandonderen> yeah, but if it is bug-free why do you need a maintainer?
[09:13:00] <piacentini> Notice; I am not saying there are no problems, just that we have discussed this in detail, and splitting/limiting does not solve the issue of unmaintained games
[09:13:08] <cvandonderen> there should be no ABI breakage between KDE versions
[09:13:12] <dimsuz_> ...while we don't have much of an active devs. but that's another question, let's hold it for now ;)
[09:13:14] <piacentini> cvandonderen; you are right
[09:13:21] <scherfa> it gets boring if a game did not get any news over a few years i think
[09:13:22] <icwiener> Umm, maybe we should discuss a) then b) and then c) :) Or am I the only one being confused by the topic variation? :)
[09:13:34] <cvandonderen> icwiener: good one
[09:13:37] <it-s> cvandonderen: because if the bugs do arise, lets say due to QT changes, there is no one to deal with that
[09:13:45] <dimsuz_> scherfa: agreed
[09:14:03] <piacentini> Ok, so option A
[09:14:15] <piacentini> There is no reason for it imo, and it is draconian
[09:14:21] <it-s> guys. there is no such thing as bug free.
[09:14:21] <piacentini> Not in the spirit of KDE at all
[09:14:27] <it-s> this is not Windows
[09:14:31] <cvandonderen> scherfa: look at MS mine sweeper ;-)
[09:14:34] <it-s> Linux changes all the time
[09:14:38] <it-s> almost every day
[09:14:43] <scherfa> Great games shouldn't be rejected ...
[09:14:53] <it-s> any of this changes may introduce bugs
[09:15:01] <piacentini> scherfa; agreed. So we should not accept bad games :)
[09:15:08] <it-s> and once they do - who is to fix them?
[09:15:20] <piacentini> But there is kdereview for that, and if no one steps in to reject, they are accepted per KDE's global policies
[09:15:22] <scherfa> piacentini, yes ...
[09:15:25] <icwiener> piacentini: I think locking kdegames for inclusions is not a good thing. Blocking it from ne GSOC contributions is a valid approach, but generally I would not lock the module.
[09:15:37] <piacentini> icwiener; agreed about GSoc
[09:15:39] <Parkotron> What about option A*, KDEGames should not accept new games that have not had at least a couple of successful releases in extragear?
[09:16:14] <josef|bomba> piacentini: Minor nitpick: Passing kdereview means that the game is working fine and compliant to all quality guidelines, but not necessarily that it's an interesting and worthwhile new game.
[09:16:15] <icwiener> Parkotron: That sounds reasonable as well.
[09:16:19] <Parkotron> piacentini: We don't currently have the developers to do the review process. That's part of our problem.
[09:16:21] <cvandonderen> Parkotron: extragear releases are not done for the non-Linux platforms and hardly tested
[09:16:26] <piacentini> Parkotron: extragear in KDE is not an intermediary place before release. There is playground and kdereview for that
[09:16:40] <dimsuz_> i have a simple question: if we will accept a new games from time to time, doesn't this mean module will grow infinitely? :)
[09:16:48] <icwiener> cvandonderen: But they show commitment, no?
[09:16:48] <piacentini> Note: I DO think that we have a problem, just that these solutions appear not to solve them
[09:16:53] <it-s> but right now we got quite a few games that are rather low quality when compared to competition
[09:17:06] <it-s> I would really like to see them go
[09:17:07] <scherfa> would be nice to have a quality standard on new games: playable, looking, ... quality of code etc.
[09:17:15] <piacentini> dimsuz: on Akademy 2008 we said that there was no problem if we had 500 games, given that A) there is a mantainer b) they work
[09:17:26] <piacentini> Distros/users will choose the ones to install
[09:17:28] <Parkotron> piacentini: I know. But is it so strange an idea to ask a game (and its dev) to prove itself, before we take over responsibility for it.
[09:17:28] <it-s> so that our dev power doesn't have to waste time with those
[09:17:31] <piacentini> As they already do btw
[09:18:01] <piacentini> Parkotron: no. So maybe we should be more strict before allowing games to move from kdereview or playground to the module
[09:18:02] <cvandonderen> What I would do is: ask KDE sysadmins for a place for old-dumped games on the SVN
[09:18:10] <dimsuz_> piacentini: i see
[09:18:19] <cvandonderen> don't release them and if somebody wants to hack on them it is still there
[09:18:20] <piacentini> cvandonderen: there is this already, unmaintained
[09:18:39] <piacentini> From there they can return to playground, and then start the whole cycle again :)
[09:18:45] <cvandonderen> yeah
[09:18:54] <cvandonderen> that would work
[09:18:55] <it-s> piacentini: but I would rather prefer an extraear module for this
[09:18:57] <piacentini> I agree that we have some bad games
[09:19:04] <pinotree> (note that unmantained means no translations, no atomatic tools, nothing, just a dump for something dead with *no* further releases)
[09:19:10] <Parkotron> piacentini: I think the issue is that we don't currently have the man power to decide things on a case by case basis, so we need to set rules that we can refer to.
[09:19:15] <piacentini> it-s; could be, if they are working
[09:19:15] <dimsuz_> so i guess that boils down to: a) we won't restrict module for enclusion of new games b) we should have some quality review on each game. BUT: we need a manpower :)
[09:19:31] <piacentini> Parkotron, dimzuz; agreed
[09:19:39] <piacentini> So the problem is manpower, not the policies :)
[09:19:49] <cvandonderen> I can go over the games over the next few weeks and see what has to improve and make a list of that
[09:19:54] <it-s> actually it's both
[09:19:58] <piacentini> I think that if a game becomes unmaintained we can move to a extragear-type module
[09:20:09] <piacentini> So only maintained ones are in the main module
[09:20:12] <it-s> that was the initial idea
[09:20:20] <dimsuz_> piacentini: yes. it seems like every problem we have is in the end leading to "we have a little manpower" :)
[09:20:31] <piacentini> But this selection has the criteria of unmaintained, not quality/size/whatever
[09:20:40] <piacentini> One is objective, the others are subjective...
[09:20:47] <Parkotron> We also have the problem that since we've already got some less than stellar games, it seems unfair to reject new games that still aren't great, but exceed the quality of ones already in the module.
[09:20:48] <it-s> the thing is - even if we ask, we are not getting any fresh manpower right away
[09:20:49] <scherfa> piacentini: And then one year in extragear and next one in kdegames again?
[09:20:59] <piacentini> Parkotron: precise
[09:21:12] <it-s> so we must re-organize the module to be maintainable by the limited hands we got
[09:21:19] <piacentini> scherfa: if there is no maintainer, I believe it can remain in extragear
[09:21:29] <piacentini> until it breaks, and then it is moved to unmaintained
[09:21:40] <josef|bomba> Parkotron: agreed, since anything else would drive more potential future contributors away
[09:21:43] <piacentini> Distros/users can pick games from extragear, so there is no loss
[09:21:49] <zhongjiecai> Is it a good think to setup some kind of standards for coding, like the main structure and parts to parts? This may eventually solve the maintainer problem as game codes are in almost the same structure.
[09:22:17] <cvandonderen> there is the code style guide already right?
[09:22:19] <it-s> zhongjiecai: good one +
[09:22:25] <piacentini> zhongjiecai: enforcing strict rules is probably good for some projects, but I believe kdegames is an experimentation ground for KDE technologies
[09:22:26] <Parkotron> zhongjiecai: I honestly don't believe it's that big of a deal.
[09:22:32] <piacentini> So it must remain free
[09:23:04] <piacentini> Of course, we should enforce reuse, libkdegames, etc
[09:23:15] <icwiener> *encurage :)
[09:23:17] <dimsuz_> ++libkdegames cleanup
[09:23:21] <it-s> piacentini: it was. i don't see any ground breaking right now
[09:23:26] <scherfa> piacentini: Yes, that procedure should not be too fast
[09:23:27] <piacentini> I kind of expect that Gluon Creator will change this thing a little bit
[09:23:48] <it-s> piacentini: definitely
[09:23:49] <piacentini> But this (Gluon) is another topic
[09:23:58] <pinotree> dimsuz_: (you still have the tool i gave you the other day, right?)
[09:24:02] <Parkotron> I mean no offence to the Gluon guys, but Gluon's been the next big thing for a few years now.
[09:24:10] <it-s> piacentini: yes. that is why we are not bringing it up :)
[09:24:33] <piacentini> Parkotron: and C++ games will continue to exist for several years at least in our tree
[09:24:41] <dimsuz_> pinotree: right :D Looks like i'm the person who always speaks about this cleanup, so i should be the one to use your tool ;)
[09:24:51] <Parkotron> piacentini: I certainly have no porting plans. :)
[09:24:52] <piacentini> I kind of look at the stagnation of Gnome games as an example
[09:25:09] <piacentini> It comes from draconian policies and top-down decisions, and ends up with no community of devs at all
[09:25:16] <piacentini> We at least have some devs from time to time
[09:25:27] <it-s> Parkotron: it has, but it is finally getting there in terms of functionality
[09:26:03] <it-s> piacentini: true
[09:26:14] <Parkotron> it-s: I guess I just wanted to say, we shouldn't be making any plans based on Gluon, until we have an actual copy of Gluon to base them on. :)
[09:26:23] <it-s> that is why we must not reject the new contributions
[09:26:33] <it-s> Parkotron: 100% agree
[09:26:36] <piacentini> Parkotron: I think our Gluon plans run in parallel to what we already have
[09:26:47] <Parkotron> For sure.
[09:27:18] <it-s> so, we accept the new contributions, but we impose some quality rules on them
[09:27:19] <Parkotron> So who here has a game in playground in active development?
[09:27:42] <xMDKx> Parkotron, I
[09:27:47] <it-s> my initial suggestion was - acceptable parity (feature-vise) to the competition
[09:28:09] <Parkotron> Could such folks introduce themselves and their games?
[09:28:09] <dimsuz_> it-s: what if there's nothing to compare with? :)
[09:28:32] <it-s> and by competition I mean Gnome, MS, and MAC standard package. not to overdo here of course
[09:28:44] <it-s> dimsuz_: then we find the closest possible
[09:29:04] <xMDKx> Well, I'm developing KWarBots, a game where you can program a robot to fight against others
[09:29:16] <scherfa> dimsuz_: Play it and you could compare it or you like or dislike the game ...
[09:29:20] <it-s> dimsuz_: oh please Dima, not like any of our games are super innovative :)
[09:29:45] <zhongjiecai> I'm maintaining KBlocks (refactoring)
[09:29:50] <Parkotron> xMDKx: Thanks.
[09:30:00] <it-s> dimsuz_: most of them are just a straight, shameless clones
[09:30:06] <Parkotron> zhongjiecai: Has that code been merged yet?
[09:30:09] <piacentini> Don't forget that kdegames is a good place from where developers graduate to work on other KDE modules, like kdelibs, Plasma, etc. Working on a game (even a simple one) is a great way to enter the community
[09:30:24] <it-s> piacentini: right
[09:30:41] <it-s> another reason why we should not restrict submissions
[09:30:43] <piacentini> The price we pay for this is a little lack of consistency...
[09:30:43] <scherfa> piacentini: Sure. And try new technique like qt animation ...
[09:31:26] <cvandonderen> scherfa: or QML
[09:31:32] <piacentini> But it is worth it imo, as the best games get picked by the distros, and the not so good ones get mostly ignored. I agree however that we should move them to someplace if they become unmaintained for 6-12 months
[09:31:43] <wolfgang61> scherfa: or Python
[09:31:51] <icwiener> Umm, is this still about the inclusion policies?
[09:31:55] <dimsuz_> it-s: okay okay :) was theoretisizing i guesss :)
[09:32:08] <Parkotron> icwiener: I think we've drifted off topic. :)
[09:32:10] <piacentini> wolfgang61: your game is probably the first KDE application in Python, isn't it?
[09:32:22] <zhongjiecai> Parkotron : nope. It's in playground now. To be safe I think it might need some tests?
[09:32:46] <Parkotron> zhongjiecai: You'd have to ask piacentini. :)
[09:32:48] <wolfgang61> piacentini: there are smaller ones, like guidance-power, but Kajongg is the first full sized one, I guess
[09:32:49] <piacentini> zhongjiecai: I sent an email to the list last week, imo you should merge and test
[09:32:52] <it-s> so my proposal is: we create Extragear module. All the low quality, and no immediate maintainer games got there. we allow adding of new games, but thy will initially go to extragear. If we see that the maintainer is still active after they are in, and it's a quality product - we allow it into the module
[09:33:21] <dimsuz_> piacentini: and also a quality. because often we have new games from people who learned C++ and Qt to some good degree, but not learned to structure their code, use common idioms, etc. that leads to unmantainable code. and that is a problem.
[09:33:24] <piacentini> it-s: first part of your proposal I think it is ok. Second is against the global KDE policies, so I do not think it is good
[09:33:26] <pinotree> try to avoid the move-between-modules ping-pong, please
[09:33:42] <Parkotron> it-s: We are not allowed to move anything that doesn't have a maintainer. The only place such apps can go is tags/unmaintained.
[09:33:49] <it-s> pinotree: why?
[09:33:50] <zhongjiecai> piacentini : Yes, I did tests on my own. I'll merge the code next week if you agree~
[09:33:54] <icwiener> pinotree: I just wanted to add that. It'd be a pain for both packagers and users.
[09:34:04] <pinotree> icwiener: and translators
[09:34:08] <piacentini> zhongjiecai: agreed, as per the email I sent to the list. Go on :)
[09:34:09] <icwiener> pinotree: Sure.
[09:34:22] * pinotree raise the i18n/l10n flag here
[09:34:32] <zhongjiecai> piacentini : Thanks! :)
[09:34:35] <wolfgang61> I would keep the structure simple - so harden the kderewiev process - it is quite easy to get in now I think
[09:34:39] <it-s> but they do have a maintainer. we have a few active devs like Parkotron, and dimsuz_ who do *maintain* them all right now
[09:34:48] <dimsuz_> so being a new-contributor entry place is a good thing on one side, but it leads to games bloat on the other side
[09:34:51] * piacentini remembers discussing this before... and we concluded already that unmaintained is the place to go..
[09:35:20] <piacentini> it-s: ok, if we have something like a KDE-games maintainers tag we can use
[09:35:21] <scherfa> How long does a game take in unmaintained state to get into another module?
[09:35:25] <it-s> piacentini: in that case the large portion of our current module must go there right now
[09:35:29] <icwiener> A game that is unmaintained but works does not have to go to "unmaintained".
[09:35:39] <piacentini> Exactly
[09:35:49] <dimsuz_> it-s: a little correction: i'd call myself a passive maintainer :) i do fix crashes/bugs, but i'd wish to implement new features which i don't.
[09:35:52] <piacentini> Nothing work with something that works and has few non-fatal bugs
[09:35:55] <Parkotron> it-s: I think you overestimate the amount of maintenance done by people outside their own games.
[09:36:11] <it-s> dimsuz_: that is good enough
[09:36:14] <piacentini> People, we have a very low bug count in general
[09:36:26] <piacentini> and serious issues usually come from Qt regressions
[09:36:27] <icwiener> Yay!
[09:36:29] <icwiener> :)
[09:36:36] <cvandonderen> dimsuz_: I have the same problem with working on KDE Windows
[09:37:03] <cvandonderen> piacentini: file bugreports with Nokia/Qt then ;-)
[09:37:05] <scherfa> But bugs != playable
[09:37:19] <Parkotron> icwiener: Things that work but are unmaintained can be left were they are, but I don't think they can be moved somewhere else.
[09:37:22] <dimsuz_> scherfa: right :)
[09:37:23] <Parkotron> pinotree: Is that true?
[09:37:38] <zhongjiecai> I think if we could separate the game engine, controller, GUI, and network, then the games should be easier to be maintained even by people who do not know the code before
[09:37:41] <icwiener> Parkotron: Why would that be?
[09:37:43] <pinotree> it can be moved to unmaintained
[09:37:59] <icwiener> Parkotron: They could not be moved to extragear?
[09:38:05] <icwiener> Ah, KDE SVN policy?
[09:38:10] <it-s> zhongjiecai: that is what Gluon is all about
[09:38:17] <piacentini> icwiener: correct
[09:38:19] * pinotree remembers extragear is not a dump
[09:38:24] <it-s> zhongjiecai: once it's ready that is what will happen
[09:38:33] <Parkotron> pinotree: Exactly.
[09:38:38] <zhongjiecai> it-s : Sounds nice~ :)
[09:38:39] * icwiener just thought of technical reasons.
[09:38:44] <it-s> pinotree: of course it's not. but it's a good place to have
[09:39:04] <it-s> no one says we should dump anything tere
[09:39:07] <it-s> there
[09:39:18] <it-s> but having it will give us to advantages
[09:39:21] <Parkotron> it-s: Extragear is for devs who want to do their own thing. Sending an app without a developer there make no sense.
[09:39:29] <piacentini> OK, so let us not get back to what we discussed two years ago, I propose. There is no problem in having 500 games in module. Once one breaks and there is no maintainer, it is moved to unmaintaned for the next cycle
[09:39:33] * cvandonderen really thinks there should be a list first with unrecoverable games and games that can be 'helped'
[09:39:34] <pinotree> +1 Parkotron
[09:39:52] <piacentini> The same as any other KDE app
[09:40:54] <xMDKx> piacentini, agreed
[09:41:01] <scherfa> 500? apps like old shareware cd collections? With no quality and only quantity
[09:41:15] <piacentini> scherfa: this is just the SVN structure
[09:41:16] <it-s> piacentini: actually there is something wrong with that. our games very in terms of quality greatly. that means that people will have different opinions of our module depending on a game they start first.
[09:41:27] <it-s> scherfa: +++
[09:41:28] <piacentini> Does not translate into what users get, this is the job of distros/packagers
[09:41:54] <piacentini> This is the important point, it is JUST the SVN structure
[09:42:04] <icwiener> If I may try to conclude about A): Inclusion goes over EG with some quality assurance. New games are allowed, just not from GSOC. Unmaintained and broken games go to tags/unmaintained and games that are unmaintained but work, can stay. Does that reflect the state of discussion?
[09:42:15] <scherfa> piacentini: svn is not the problem. i think over a default kde installation with dozens of kde games a new user could get confused
[09:42:19] <piacentini> If it is decided to reorganize KDE and put all apps in the KDEAPPS module the issue would be the same
[09:42:26] <it-s> piacentini: and why do you think they ship our games all separately, and selectively, while the same people package Gnome games as a one happy bunch?
[09:42:30] <cvandonderen> icwiener: think so
[09:42:30] <piacentini> scherfa: that is the problem of lazy distros
[09:42:44] <scherfa> piacentini: Sure
[09:42:48] * icwiener thinks about creating a wiki page in parallel.
[09:42:59] <piacentini> it-s: we discussed that already, and the solution was to do a KDE Games suggestion of sets
[09:43:01] <piacentini> remember?
[09:43:06] <Parkotron> it-s: That's a Gnome-games policy.
[09:43:16] * Parkotron reminds maintainers to update http://techbase.kde.org/Projects/Games/Maintainers.
[09:43:17] <it-s> piacentini: yes, and that failed
[09:43:18] <piacentini> You tried to implement that, and game authors complained
[09:43:34] <piacentini> So changing this into "move bad games to another place" is the same thing, and will fail as well
[09:43:39] <piacentini> For the same reason
[09:43:49] <it-s> so what do we do
[09:43:58] <it-s> we have not decided anything yet
[09:44:10] <piacentini> The SVN structure is not the problem imo. If people decide it is important to have a global classification shystem
[09:44:15] <piacentini> We can vote on them
[09:44:18] <piacentini> on this
[09:44:35] <it-s> problem #1 - too many games, too few devs
[09:44:39] <piacentini> So defining a "kdegames essential" or "core"
[09:44:42] <zhongjiecai> Now only bring those 'unmaintained' games will not harm coders' feelings
[09:44:43] <scherfa> piacentini: Voting would be nice ...
[09:45:06] <it-s> problem #2 - low quality of some games drags the expectation to the whole package down
[09:45:24] <it-s> problem #3 - most of those low quality games are even unmaintained
[09:45:47] <piacentini> it-s: well, but... what can we do? If I have a GREAT game, should I prevent other not so great ones from sharing my SVN directory?
[09:46:02] <icwiener> it-s: Where does #2 come from? I mean, how was that problem detected?
[09:46:05] <piacentini> Again, unmaintained is a technical/objective criteria
[09:46:15] <piacentini> quality is a subjective one!
[09:46:44] <piacentini> I totally understand it-s frustrations, specially as the responsible for lot of the artwork
[09:47:17] <it-s> icwiener: I'm yet to see a single commercial distro that ships our module in tact.
[09:47:22] <piacentini> And I understand as well the issue of quality. I just think that we should preserve the global policies and the spirit of KDE
[09:47:29] <it-s> icwiener: while Gnome games always are
[09:47:35] <icwiener> it-s: You mean in the standard installation?
[09:47:44] <it-s> icwiener: yup
[09:47:45] <piacentini> it-s: why is this important at all?
[09:48:01] <icwiener> it-s: As pointed out by Parkotron, this might be due to GNOME shipping policy.
[09:48:04] <piacentini> It is a non-issue to me. In fact I prefer that they choose only the ones that they think are the best
[09:48:09] <it-s> piacentini: becasue that means that our module is not as well exposed as it could have been
[09:48:37] <piacentini> I respect your opinion, but to me I do not see this as a reason to reorganize the SVN structure
[09:48:40] <piacentini> or push people away
[09:48:52] <scherfa> Should kdegames have a package maintainer on its own?
[09:48:56] <it-s> icwiener: oh please. policy-shmolicy. if the packagers decide to separate the will do that, and no policy will stop them
[09:49:10] <icwiener> Well, removing all the apps that are not shipped by dostros does not change anything, does it?
[09:49:11] * Parkotron would think it pretty odd if a default distro installation came with all 39 of our games. Even if every one of those games was awesome.
[09:49:11] <it-s> icwiener: GNOME does not package the stuff themselves
[09:49:17] <piacentini> it-s: but we all know packagers of some distros are lazy :)
[09:49:34] <piacentini> scherfa; we do have one
[09:49:47] <piacentini> but he is very busy and not really "maintained" :)
[09:49:53] <scherfa> piacentini: Upps, sorry;-)
[09:49:57] <pinotree> Parkotron: right, for example i find strange distros still ship kpat, what do you think? :-P
[09:50:04] <piacentini> It is Matt Williams
[09:50:36] <icwiener> pinotree: :)
[09:50:42] <icwiener> Parkotron: Get him!
[09:50:44] <icwiener> :D
[09:50:50] <piacentini> BTW, this is something we should decide. There are other people that are probably going to have more time (and already have) for this. Should we find a replacement for Matt?
[09:50:51] <it-s> piacentini: but in the same time nothing is stopping them from shipping all of the 16 GNOME ones
[09:51:06] <Parkotron> piacentini: What are the actual duties?
[09:51:19] <piacentini> Let us look this up on techbase ...
[09:51:22] <pinotree> (dishes, floor cleaning, ...)
[09:51:43] <piacentini> BTW, it is not a module maintainer. It is a module release coordinator.
[09:51:56] <piacentini> So duties are related to release preparation, advertising deadlines, etc
[09:52:30] <icwiener> To come up with a strong opinion: We should not move out games that are working[tm] and do not have a replacement.
[09:52:42] <wolfgang61> https://techbase.kde.org/Projects/Release_Team#Module_Coordinators
[09:52:49] <piacentini> https://techbase.kde.org/Projects/Release_Team
[09:52:57] <it-s> even if no one plays them because the ary righ down awful?
[09:53:16] <icwiener> it-s: How would you measure it?
[09:53:25] <it-s> good qustion
[09:53:43] <scherfa> it-s: Ugly games could be replaced ...
[09:53:54] <Parkotron> piacentini: Do we know if milliams is keeping up with the release team stuff? I know he's not active within the module, but I have no idea if he's doing his job on the release team.
[09:54:04] <it-s> I think I should make a pool on the planet, and also try to put it on some othere sites, just to see if anyone even plays our games
[09:54:11] <mikelima> scherfa: ugly games should get better artwork.
[09:54:15] <icwiener> The kdetoys maintainer tried to move amor because it's severily broken but there were people complaining because it still works for their use-case.
[09:54:29] <mikelima> Badly designed games should be reworked...
[09:54:29] <piacentini> Parkotron: let us email him, I think nothing is broken
[09:54:32] <pinotree> icwiener: there ae commits recently in amor
[09:54:41] <mikelima> Replaaacing them mens working from scrtch.
[09:54:49] <icwiener> pinotree: I know. The kdetoys maintainer is currently trying to fix it.
[09:54:52] * dimsuz_ thinks about some tool to allow simple user feedback gathering. to understand which games are played which are not. and why
[09:54:57] <scherfa> mikelima: And a maintainer ...
[09:55:08] <wolfgang61> it-s: maybe a feedback function in the about dialog?
[09:55:10] <mikelima> sure...
[09:55:24] <it-s> wolfgang61: no one will ever notice that one :)
[09:55:31] <mikelima> but for the ugly part, that's artists work :)
[09:55:41] <josef|bomba> dimsuz_: There used to be survey.kde.org, but I think it was deactivated because nobody used it.
[09:55:47] <it-s> not really. I can only do as much
[09:55:51] <Parkotron> I think we need to be very careful about use feedback. If we don't have the manpower for devs to work on what they want to work on, getting feedback to work on other things isn't going to help.
[09:56:04] <it-s> if the game mecchanics don't allow for ccertain things - I can't add them
[09:56:06] <piacentini> Parkotron: +1
[09:56:32] <it-s> I don't want any feedback per say
[09:56:39] <icwiener> + user feedback can be discouraging.
[09:56:40] <dimsuz_> manpower strikes again :)
[09:56:47] <it-s> I want a way for us to know what games are played, and what aren't
[09:56:51] <wolfgang61> it-s: maybe a nice question at the end of a game (suppressable)
[09:56:58] <mikelima> it-s, well, sure.
[09:57:05] <Parkotron> it-s: What would you do with that information?
[09:57:26] <it-s> Parkotron: that information will allow us to safely remove games that are not played
[09:57:31] <mikelima> Do we have to-do lists for the "lacking" games?
[09:57:33] <scherfa> it-s: Even a system that count the time a game was played ... every game could silently report that. Make things easy to vote.
[09:57:47] <Parkotron> scherfa: Spyware.
[09:57:50] <mikelima> That could make them better.
[09:57:53] <icwiener> Or just played by people who do not want to give feedback.
[09:57:59] <cvandonderen> mikelima: I put that point down twice already without response
[09:58:11] <icwiener> There is the Debian Popularity contest. :)
[09:58:18] <scherfa> Parkotron: Shame on me :-)
[09:58:23] <icwiener> http://popcon.debian.org/
[09:58:33] <it-s> how about we add a send feedback function into the tool menu?
[09:58:52] <icwiener> Err: http://qa.debian.org/popcon.php?package=kdegames
[09:58:52] <it-s> and the firest time a game starts to will ask if user wants to paticipate
[09:58:54] <mikelima> I tried putting the games on happypenguin, but it did not seem to gain useful reactions.
[09:58:56] <piacentini> icwiener: yup
[09:59:30] <icwiener> libkdegames-dev is only installed on 34 systems. I guess we can drop that.
[09:59:31] <icwiener> :D
[09:59:46] * pinotree smacks icwiener
[10:00:18] <scherfa> Sorry guys have to leave now ... i think we are getting closer. Let me hear what solution was found on kdegames-devel mailinglist. Thanks
[10:00:33] <Parkotron> scherfa: Someone will post the log somewhere.
[10:00:50] <scherfa> Parkotron: Thanks
[10:00:55] <pinotree> icwiener: note that with popcon data, given that there was no debian release with kde4, kde4 games for sure have less votes (as they get no votes from oldstable/stable installations)
[10:01:15] <icwiener> Ok, seriously, I think these statistics are nice to decide on priorisation ... but not for exclusion. there are many many more users there who do not participate in surveys and such.
[10:01:20] <piacentini> I missed the start, is there an agenda posted? Just to see if I can postpone lunch for some more time :)
[10:01:34] <it-s> dimsuz_: can you create such a function globally in libkdegames?
[10:01:42] <it-s> dimsuz_: ha difficualt is that?
[10:01:58] <icwiener> pinotree: Yes, true.
[10:02:11] <it-s> dimsuz_: just to reposrt the playtime
[10:02:29] <Parkotron> piacentini: Nope. No schedule.
[10:02:46] <jobermayr> While translating I noticed that Amarok team included such a dialog in newest devel version. But I never have seen it because I am waiting that openSUSE provide me that version.
[10:03:07] <it-s> jobermayr: :) I know SuSE can be so slow at times
[10:03:10] <icwiener> They do not have manpower issues. :)
[10:03:19] <mikelima> Downloadable content may also serve as an indication some game is being played...
[10:03:36] <it-s> mikelima: yes but twe don't have it in every game
[10:03:45] <icwiener> The dialog itself is rather nice ... but again, you cannot conclude just because you do not receive feedback, your game isn't played at all.
[10:03:46] <it-s> talking about quality imparity :/
[10:03:47] <Parkotron> icwiener: Every opensource project has manpower issues, because they could always be doing more. :)
[10:03:59] <it-s> icwiener: yes you can :)
[10:04:17] <icwiener> Parkotron: Ok then their mp issue is not grown to a problem yet. :D
[10:04:20] <mikelima> it-s: well, then we could improve in that area.
[10:04:22] <dimsuz_> it-s: hm. needs investigation. where would it post it to?
[10:04:39] <icwiener> it-s: Ok, you can, but (imho) you shouldn't. :)
[10:05:01] <piacentini> I think amarok used LikeBack
[10:05:06] <piacentini> but I am not sure
[10:05:11] <it-s> emil can make a simple PHP web backend to collect the data into a mysql db
[10:05:12] <piacentini> But only for the beta builds
[10:05:18] <it-s> emilsedgh: are you with us?
[10:05:28] <dimsuz_> yep, it's likeback
[10:05:44] <emilsedgh> ye it-s
[10:05:47] <icwiener> And yep, they use it only for beta builds.
[10:05:48] <Parkotron> Before we launch a big project to harvest user information, I think we should have a clear plan of what that data would be used for. I see it being a lot of work, but don't see it helping make this decision easier.
[10:06:10] * icwiener is with Parkotron here.
[10:06:18] <it-s> icwiener: why? we need to know. at least just so we could determine what games need more exposire/advertising
[10:06:42] <josef|bomba> If KDE apps have feedback collection dialogues, then there should also be desktop-wide (xdg) configuration for this, so that users don't get annoyed and have to turn off all such dialogues individually.
[10:06:51] <icwiener> it-s: Ah, ok. I just meant that we cannot drop games because of the lack of feedback.
[10:07:26] <wolfgang61> mikelima: kajongg has been downloaded 366 times from kde.apps but almost no feedback from there.
[10:07:28] <Parkotron> it-s: Let's say it comes back that 20000 people play KPat, 10000 play KMines and 500 play Bomber. What do we do with that info.
[10:07:33] <icwiener> There already is the kde-wide way of giving feedback: Help->Report Bug ...
[10:07:42] <dimsuz_> i feel that as we didn't come to any desicion to the initial problem(s), we started to work on others which look like we can decide something on :)
[10:07:46] <it-s> icwiener: personally I don't see why not, save for santimetal reasons
[10:07:53] <dimsuz_> s/work/discuss/
[10:08:16] <piacentini> dimsuz: at least we are meeting again :)
[10:08:22] <it-s> Parkotron: we now will know Bomber is not too popular, and we can start investigating why
[10:08:43] <it-s> Parkotron: not that you need to investigate in this particilar example
[10:08:50] <Parkotron> it-s: What if the main reason is that people don't like scrolling bomber games.
[10:09:08] <icwiener> Because there are users out there who will be disappointed if their game disappears. That's unfortunate if the game worked. So imo we should not drop working games, just broken ones.
[10:09:09] <josef|bomba> icwiener: The report wish/bug dialogue is not meant for casual users.
[10:09:14] <it-s> Parkotron: then we now have a condidate for replacement :)
[10:09:29] <icwiener> With a later discused definition of working and broken.
[10:09:44] <Parkotron> I guess I just don'
[10:10:20] <icwiener> t have enough time?
[10:10:21] <Parkotron> t see anyone keen to fix up the games that are popular. I only see people (myself included) interested in working on the games they like.
[10:10:24] <icwiener> Oh :)
[10:10:41] <it-s> ok but this just means : *lets leave it all the way it is now, and not do anything*
[10:10:57] <it-s> this means we just waisted a hour for nothing
[10:11:11] <zhongjiecai> Still, waiting for users' feedbacks could be quite a long term future result... and it is not helping us now on the current issue...
[10:11:13] <icwiener> Discussion is never waisted time.
[10:11:14] <it-s> why, pray tell me, did I have to get up so early?
[10:11:52] <Parkotron> So if we knew that everyone loved Kapman but was frustrated by its (hypothetical) low quality, I think we just end up with more guilt, but no more progress.
[10:12:06] <zhongjiecai> In my view, we could (1) mark current active games as 'well maintained', and candidate for user feedbacks.
[10:12:08] <it-s> icwiener: discussion with no results is a wasted time, sine the main purpose of the discussion is to have a descission made
[10:12:47] <dimsuz_> it-s: sometimes making a desicion is a several-step process ;)
[10:12:52] <zhongjiecai> (2) mark those unmaintained games as 'Dangerous' (kidding) and inform (or find) maintainers.
[10:13:20] <icwiener> I think we kind of decided about the inclusion policy, didn't we?
[10:13:21] <Parkotron> it-s: Ruling out possible decisions is still progress (although not terribly rewarding).
[10:13:48] <zhongjiecai> (3) Newly introduced games are marked as 'Unknown', and should first follow some rules of coding, and wait for user feedbacks.
[10:14:01] <it-s> oh, then how about a pop up gialogue at the game start: "This game has not been maintained sine [DATE]. Use at your own risk!"? :P
[10:14:26] <icwiener> With the OK button text "Delete my data"? :D
[10:14:27] <zhongjiecai> If these three points are not bad, we could focus on detailed discussion on each then
[10:15:21] <icwiener> zhongjiecai: This too sounds like another layer of maintenance efforts. Meaning: Sounds nice but sounds as if it will be unmaintained in a bit.
[10:15:34] <Parkotron> icwiener: I agree.
[10:16:30] <zhongjiecai> icwiener : But once this structure is set and applied, not much efforts would be needed in future
[10:16:55] <zhongjiecai> Like we would only care more for 'new games' then
[10:18:10] <Parkotron> So I think the number one thing we should decide is what do we want to do about the inclusion of new games? Mancala is currently sitting in KDEReview. As far as I know, no one has reviewed it yet, so if it sits there for another week, it will get in without review.
[10:18:17] <dimsuz_> zhongjiecai: that has some weak points in that. 1) what if there won't be user feedback? 2) what if this feedback would change? 3) who will support this system/check rules/qualify games?
[10:18:39] <icwiener> Parkotron: haha :D I just started a similar sentence but you came first. :)
[10:18:46] <pinotree> Parkotron: this is the part of the "review" process which is mostly controversial
[10:18:53] <zhongjiecai> Maintainers or authors of a game should handle the positions of their games, that is, if you decide to leave, you should find a new maintainer, otherwise you should take responsibility of moving your game to 'unmaintained' position.
[10:19:06] <icwiener> Parkotron: It could go to EG, no?
[10:19:08] <pinotree> "bing two weeks" does not imply that after two weeks you get immediately in without anyone say anything
[10:19:20] <pinotree> s/bing//
[10:19:26] <icwiener> As the first game following our new policy [tm] ;)
[10:19:37] <pinotree> (at least imho)
[10:19:39] <Parkotron> pinotree: Unfortunately it has often enough in the past for KDEGames.
[10:19:54] <pinotree> still does not mean it is good ;)
[10:19:56] <it-s> ok. lets face the facts. all this talk is nice and democratic, but the truth is on daily bases there are only four people who are in this cahnnel: me, half-left, dimsuz, and Parkotron (and pinotree but he is a tree, so does not count a people).
[10:20:00] <zhongjiecai> dimsuz_ : actually feedbacks are considered optional to me, quite unreliable.
[10:20:16] <it-s> so, to me it looks like this is the manpower we have
[10:20:47] <it-s> and knowing this - 2 devs, and 2 artists, I would relaly like to see the module go down in size
[10:20:55] <icwiener> it-s: There are maintainers that do their job but aren't here.
[10:20:58] <Parkotron> it-s: That's harsh. icwiener is often here. So are others. majewsky commits more than anyone else, but he's almost never online.
[10:21:07] <zhongjiecai> dimsuz_ : But my points would be affected by feedbacks, as we could always find a way to mark a game
[10:21:22] <icwiener> wrodewald is also very active bot barely here.
[10:21:29] <it-s> I'm overexhagerating, but none the less
[10:21:55] <mikelima> it-s: as an artist, I think you have problem with NEW games being added...
[10:21:56] <Parkotron> icwiener: wolfgang61 is a bot? ;P
[10:22:17] <it-s> we have no people to maintain 30+ games, let alone add new features
[10:22:25] <piacentini> it-s: just because someone does not log into IRC does not mean he person is not in the module
[10:22:27] <mikelima> Old games are done. Unless they get upgraded, but that's generally good, it means they are being maintained :)
[10:22:27] <piacentini> or participating
[10:22:31] <piacentini> Ian has never logged in
[10:22:36] <piacentini> as an example
[10:22:53] <piacentini> the official channel is the mailing list imo
[10:23:05] <it-s> ok. don;t pick on my words. you know perfectly well what I mean
[10:23:08] <mikelima> Ian has a timezone problem... and he managed to get online once. :)
[10:23:42] <Parkotron> piacentini: Earlier you were opposed to making games live somewhere between playground and kdegames to prove themselves. Could you explain your opposition further.
[10:24:01] <icwiener> Parkotron: Oh. :D
[10:24:02] <piacentini> Parkotron: it is just that this place is already existing, kdereview
[10:24:07] <it-s> so I would really like to bring the game count down to the games that have developers working on them
[10:24:17] <piacentini> I want to avoid us making rules that are different from the rest of the project
[10:24:22] <jobermayr> My problem is that I do not understand any kind of source code. So I can report only bugs and create "accounts" on bugs.kde.org ...
[10:24:28] <it-s> this would also allow us not to think twice about letting new people in
[10:24:30] <piacentini> If kdereview is broken, it is imo better to fix it
[10:24:46] <piacentini> But it is just a quick thought
[10:25:37] <piacentini> Honestly, I do not think anything is really requiring desperate measures. It is not like we are all broken for 4.5 or something like that.
[10:25:38] <Parkotron> piacentini: Well we have a problem that other modules don't have. There is a finite number of possible graphics apps before you see major overlap. There are an infinite number of possible non overlapping games. I think we might need special rules to address that fact.
[10:25:54] <piacentini> Parkotron: sure, it is a good point
[10:26:25] <piacentini> But moving (as explained) has some costs, like translation moves, etc
[10:26:47] <piacentini> So introducing a new place instead of kdereview is something that needs to be considered with the whole project in mind
[10:27:05] <piacentini> And it is not like we have 20 games in the queue, so...
[10:27:11] <icwiener> it-s: That would make things easier from the kdegames point of view. But what about the POV from the dismissed games (users?). They would just lose a game that was working fine for them jsut because it was unmaintained. That's not how it should work, imho. If KDE would apply a policy like that, half of KDE would be gone tomorrow.
[10:27:18] <Parkotron> piacentini: I think it's not so much proving the code quality as it is the persistance. If an app can make (say for example) two quality releases in one year (from extragear or kde-apps or somewhere else) then the chances are much better of them sticking around once they get into the module.
[10:27:23] <piacentini> Maybe we should have someone in the module reponsible for kdereviews?
[10:27:51] <piacentini> Parkotron: moving from kdereview to extragear first is something I believe is ok with the KDE policies
[10:27:55] <piacentini> And then graduating to kdegame
[10:28:12] <Parkotron> piacentini: Exactly.
[10:28:13] <piacentini> So I would be ok with it, but I am not sure if Helio (the extragear maintainer) will be
[10:28:24] <piacentini> Probably yes
[10:28:34] * icwiener likes the kdereview -> EG -> (optional) KDEGames way reasonable.
[10:29:03] <Parkotron> Well if we say it has to live there for at least a year *after* *successful* kdereview, then that traffic would be relatively low.
[10:29:04] <piacentini> ok, so this is something I believe we can propose officialy on the kdegames mailing list
[10:29:19] <piacentini> cool
[10:29:36] <piacentini> I do not oppose this plan if others believe it is a good idea
[10:30:05] <Parkotron> Does it have to be extragear, our would be allow games that have been develop on (say) gitorious and released on kde-apps?
[10:30:06] <piacentini> But to be honest, nothing guarantees a person will stick around
[10:30:08] <piacentini> :)
[10:30:27] <piacentini> Parkotron: well, we could then wait for the KDE move to git or gitorious
[10:30:31] <piacentini> which shouuld happen any day now
[10:30:44] <piacentini> And then decide how to handle this on a descentralized repository world
[10:30:49] <piacentini> How about that?
[10:31:04] <Parkotron> piacentini: What do we do with Mancala then?
[10:31:06] <piacentini> Probably the SVN policies will be reviewed after the move
[10:31:22] <piacentini> Is there a hurry?
[10:31:44] <piacentini> Honestly, it sat there for 7 months after GSoC ended
[10:31:50] <Parkotron> I don't know. Are you proposing we just say, way for 4.6?
[10:31:57] <piacentini> And it was moved now just before the new GSoC selection
[10:32:38] <Parkotron> s/, way/wait/
[10:32:44] <piacentini> Let two or three of us play and review it this week
[10:32:54] <piacentini> What about it?
[10:33:02] <Parkotron> I have 5 exams this week. :|
[10:33:11] <piacentini> And then talk to Matt (as the release coordinator) to handle this
[10:33:26] <piacentini> I can play it after Wednesday
[10:33:27] <piacentini> Will do then
[10:33:56] <josef|bomba> If it moves in, it might be a good idea to add to http://games.kde.org/news.php because right now the most recent news entry is > 2 years old.
[10:34:09] <piacentini> K
[10:34:19] <Parkotron> dimsuz_: Would you be able to review Mancala this week?
[10:34:29] <piacentini> I wil have to logout, please post the logs to the list!
[10:34:44] <dimsuz_> great desicion guys! about EG=>kdegames
[10:34:50] <dimsuz_> Parkotron: i hope i will
[10:34:53] <wolfgang61> Parkotron: No I am no bot, was just away for a while - trying to catch up
[10:34:55] <piacentini> I will keep the computer on for another 30 minutes while I feed the baby, but not looking :)
[10:35:21] <dimsuz_> Parkotron: i guess i'll be more or less available up to wednesday
[10:35:21] <Parkotron> wolfgang61: icwiener made a typo and I made a joke. Wasn't trying to pick on you. :D
[10:36:18] <Parkotron> Okay, so is this meeting over? If so we should summarise, I guess.
[10:36:51] <icwiener> Hard su summarise this. :)
[10:37:10] <icwiener> /su/to/
[10:37:34] <Parkotron> it-s: Where do the meeting logs ususally go?
[10:38:12] <it-s> Parkotron: onto the WIKI
[10:38:14] <it-s> 1 sec
[10:38:27] <icwiener> ~/logs/freenode_#kdegames ;)
[10:39:34] <it-s> Parkotron: http://techbase.kde.org/Projects/Games/IRC_Meeting#Meeting_Logs
[10:39:48] <Parkotron> it-s: Thanks.
[10:39:54] * icwiener would like to see more regular meetings about small, easy to discuss things. Like in this case the new inclusion policy.
[10:41:16] <Parkotron> it-s: So are we officially done? Can you smack the gavel?
[10:42:03] <icwiener> Parkotron: Do you want to go back to bed? :)
[10:42:40] <Parkotron> Nah. I've got a big git-svn log built up, but I don't want to flood the channel until the meeting is done. :D
[10:42:57] <icwiener> Hehe :D
[10:43:06] <it-s> alright then
[10:43:17] <it-s> this concludes our meeting for the day
[10:43:28] <it-s> thanks to everyone for joining us here
[10:44:04] * it-s hopes to see everyone again soon
