Re: Kolf: Rumours of its death have been much exaggerated
On Sat, Jul 4, 2009 at 10:16 PM, Ian Wadhamia...@optusnet.com.au wrote: I have just committed a fix to Kolf on trunk/kdegames/kolf. ... Stefan, Mauricio or whoever, please can you try out this fix. ... If it is OK and there are no further problems, the fix should be backported to the KDE 4.3 branch. Would you like me to do that? It works for me, and restore the 4.2 behavior. Wonderful detective work, Ian. I am very glad you could fix it in time for 4.3, so I would say you should backport it (if you have not done so already.) It is nice to be able to keep Kolf in kdegames for this release, because this would mean less hassle for packagers and people upgrading their systems, and also guarantee a smoother transition when the new version is ready for 4.4. Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-games-devel] Regression testing
Yes, Plasma will show severe breakage with Qt 4.4. Lowering the requirement is not an option if we want a functional desktop shell. In this case, I'd actually opt for removing kolf from the release. It's not ideal and painful, but as it seems, we have to decide between a broken Kolf and a broken Plasma, Kolf, with all due respect is less critical for most of our users. You are correct, of course. Given this choice there is really no other option. I tried to fix Kolf again today, but failed to understand why it has broken. I know the kde-games community took a shared responsibility for maintaining orphaned applications, and we are doing our best at it. But it is difficult when a major piece of technology that is not under our control keeps changing in subtle ways, and breaking our apps at every 2 or 3 months. Notice that I am not saying that the app is perfect to start with, but if you look at the last releases each broke a different KDE game in a subtle way. And every time we had a problem in the last releases it was connected to a change in QGraphicsView, which has been sort of a moving target. KMahjongg and KGoldrunner, who used KGameCanvas, did not suffer from this. Several games that used QGV did suffer at different times. Kapman broke completely, then KMines. KPat had (might still have, I am not following it) redraw issues, and Kolf is completely broken with no change in our code. KBlocks exhibits weird drawing since version 1.0, as I chose not to work around the bug that caused it with SVG elements. These redraw and display issues accont for probably 50% of our bug reports recently, if not more. All of this was understandable at 4.0, and Ian and me both spend a lot of time chasing bugs there, but it is no longer fun after almost three years. Gladly, Plasma folks are doing a very good job at keeping at least the desktop shell under relative stability and taming QGV issues. Maybe the higher visibility of their work ends up producing better/faster results when attempting to solve these issues compared to our efforts, or maybe they are just better at colaborating with the Qt people that maintain those pieces of code :) So I think it is time we lay out a plan to deal with these situations in the future. I would say we need to implement: a) Better (or any :)) regression testing at every Qt release. b) A policy where applications that have stayed in the module with no active maintainer for a given period of time need to be QA'd by the module maintainer, if no one else steps up. If problems can not be solved, they should probably be removed before the RC. Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-games-devel] Possibly release-blocking issue for 4.3 (was: Re: Problems with Kolf)
I'm taking this to k-c-d and k-d. Kolf 1.9 has no maintainer at the moment, and its source is a complete mess. This means we have only one chance: find someone who knows about a change in QGraphicsView from 4.4 to 4.5 that might be causing this problem. In this case, someone might be able to hack a fix together. (I'm well aware that someone would most probably translate to me, as I'm kind of the upcoming Kolf maintainer.) If this is not possible, I'm quite sure no one can/wants to/will waste his time to dig into the Kolf 1.9 source and find the problem. This would effectively mean to remove Kolf from branches/4.3, and probably also trunk. Well, I did a first attempt yesterday to dig into the code and try to fix it. It appears that the code tries to be too smart and reuse object items, and for some reason this is failing with Qt 4.5. But... you are right, the code is difficult to follow. I tried some obvious things first, looking at what changed in the external libs (including KPixmapCache), but so far I was not successful. Removing the app is always a possibility of course until the final RC, but as you are working on Kolf2, and we shipped Kolf in all versions of 4.x, it would be nice to make it work so that we do not create problems for packagers and people upgrading. I will do another couple of sessions trying to nail it down, but no promises. As you mention, the app code is not as tidy as it could be, but it was still working with all versions of Qt up to 4.4. BTW, there are still some redraw bugs in KMines, introduced in Qt 4.5 as well. I am not sure what to do in that case as removing KMines is not an option, and the bug does not appear to be ours... Dmitry, did you have any success looking at these? Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-games-devel] Possibly release-blocking issue for 4.3 (was: Re: Problems with Kolf)
Well, I did a first attempt yesterday to dig into the code and try to fix it. It appears that the code tries to be too smart and reuse object items, and for some reason this is failing with Qt 4.5. But... you are right, the code is difficult to follow. I tried some obvious things first, looking at what changed in the external libs (including KPixmapCache), but so far I was not successful. Removing the app is always a possibility of course until the final RC, but as you are working on Kolf2, and we shipped Kolf in all versions of 4.x, it would be nice to make it work so that we do not create problems for packagers and people upgrading. I will do another couple of sessions trying to nail it down, but no promises. As you mention, the app code is not as tidy as it could be, but it was still working with all versions of Qt up to 4.4. BTW, there are still some redraw bugs in KMines, introduced in Qt 4.5 as well. I am not sure what to do in that case as removing KMines is not an option, and the bug does not appear to be ours... Dmitry, did you have any success looking at these? I forgot to add: maybe it is already fixed in 4.5.2, just released? I am at fisl and with a low bandwidth connection, can someone please try it to verify? Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: About Kamala
Michael Pyne wrote: I mean as something distributed by kde.org as the KDE desktop environment. Obviously we can't just dump all kdelibs-using software into /trunk/KDE (even done in C++ by our best contributors), which is one of the reasons that we have extragear and playground. OK, got it. But I thought that the definition of extragear was stuff that will be released in its own schedule, and playground was for things under development and not ready yet. That was the initial assumption, and lead to the question: what we do if we want to release with KDE, and are past the playground stage, and do not have a suitable module? For instance if I were to make a Preventative Maintenance Scheduling program it would probably not be suitable to go into kdeutils or kdetoys because I don't see it as something that KDE the Project needs to solve. I understand. But by this criteria maybe we do not need all the games or kdeedu applications as well. I might *feel* that we do not need both KShisen and KMahjogg, for example. It becomes something highly difficult to define, it is good that we are having this conversation. That's actually a good lead-in, and I'm glad you asked the question. I don't personally feel that any non-traditional apps should be distributed by KDE under the K Desktop Environment banner that things in /trunk/KDE exist in (but that's just me). Now maybe I'm wrong and we're actually trailing standard practice here (e.g. does Mac OS X or GNOME include astrology programs in their localized versions for areas where astrology is important?). So in my mind the technical question is whether, wherever Kamala ends up going in SVN, there is a way to get release-team to handle packaging it as well, since right now the only framework for that is basically /trunk/KDE. Well right now when packagers do that it is at much extra effort to break up our releases. What KDE actually ships is source code for modules, unbroken. If we were to agree to some standard means of grabbing individual applications or libraries then we'd be maybe be able to say that application foo is made available for interested parties but is not part of a standard KDE desktop module. But right now I don't think that's where we're at. That was the discussion we had in the kdegames BoF at Akademy. We did not feel that the Gnome route has the best for us: they basically limit the number of games to something like 12 ou 13, and if one goes in, another one goes out. This implies the existence of someone that decides which games should be part of the module. In the long run I do not think this shapes the best community, although it *might* shape a more coherent desktop offer. That is why we thought about adding an indication to packagers inside the kdegames module. After all, the SVN structure does not have to be mirrored by distros. So we would categorize the games as part of a MINIMAL, BASIC, EXTENDED or COMPLETE subpackage, just to make the life of distros easier. Our intent with this is perhaps to attract big scale projects like Boson or other games so that they feel welcome inside our SVN structure. With this, we would have the best of both worlds: we would not limit the number and scope/size of games artificially, but we could still point distros to our pre-selected sets of applications that they could pick easily. But we did not implement this, yet. Maybe it is time to do so? And maybe with a provision for a place that applications like Kamala or your Preventive Maintenance Schedule could live, knowing that they will be tagged and released aligned with the main KDE schedule? Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: the future of kdetoys
I sorta like little amor. so cute :) Amor is the main reason my mom likes his older Linux/KDE box better than my stepfather's more powerful Win machine. She keeps teasing him that he does not have a pet cat that follows here around while surfing the internet. And she speaks with the cat too. So, we really need amor, for very selfish reasons like keeping mom happy. I will have a look at it (did not know it was unmaintained), but it does not seem to have critical bugs at first glance. Sure, an update to use svg would be nice, and if it is the only one remaining in the module maybe it could be moved to kdeutils or something. Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Soft freeze on April 7th
According to the schedule, we have a soft freeze on April 7th. For KDE Games, I want to be sure I know what this means. We have some games in playground yet, others in kdereview. Do we need to have all apps that will be in 4.1 in the main module before this date? Or can they be still in kdereview/playground and be moved before the hard freeze on May? Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
Simon Edwards wrote: Of course a shorter schedule incurs more release process overhead. I see the KDE releases more as a bus to be caught, and less as a schedule for my development. YMMV. I think Simon summarized nicely the way I see the release process, and why I think 6 months is better. In other words, less time to wait for the next bus. New features/apps may take 1 month or 12 months to be ready, we have no control over this. But when they are done, the more buses we have means less time for the bits to arrive at the hands of the average user. The main drawback to consider is the burden on the release team, but Dirk seems to agree that 6 months is doable. Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: KDE 4.1 planning
Put me down as another vote for at least trying a 6 month release cycle, with 4.1 in June. Now that the big baby is out, we can attempt to pack less changes into each release, but make them more frequent. If something is not ready by 4.1, then 4.2 is not that far away. Rinse, repeat. A 9 month interval for inclusion of new features and applications in the main release seems too long, at least for me. Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Shipping a cursor theme with KDE
Regarding this issue: as several others have noticed, the tree is closed for new features. If the theme has been developed in the public SVN and previous (even ugly/unfinished) versions of the cursors were installed in the RC or betas for testing, then I would support last minute art changes until the tagging. But this was not the case, so this feature missed the freeze deadlines. This is really simple. Something was not in the release modules at the time the freeze was done, it should have to wait for the next release. There should really be no stressing about this. I (and others) have lots of artwork-only changes for themes, and they were prevented from going in and are waiting in the sidelines for the past several months. So, to be clear, let us not try to twist the interpretations of the schedule and freezes. According to the release schedule, it seems logical that this should not be allowed to go in, and Ricardo should not even ask about it (see the Phonon move to kdereview for example.) Once this basic assumption is assumed, we can argue if an exception should be allowed, and this is an entirely different line of reasoning. Again: if we agree that new features are frozen, then we can treat this as a request for an exception, and deal with it accordingly. In this new light, I am not against granting an exception and adding the cursor theme, as the whole Oxygen was marked as somehow exempt and deemed a showstopper for release. And if you look at the bigger picture, Plasma is not subject to the freeze rules as well. Seeing that we made the *desktop* part of KDE essentially exempt from a hard freeze and some of the deadlines that apply to other modules, it is easy to see why people consider inclusion of cursors a minor thing, right? Before this creates a new schism: we had our reasons for doing this, it is a done deal, and appears to be paying off. I do not want to start a Plasma discussion here. So there is a de-facto situation: some modules are in freeze. Some are not. We can elaborate over the meaning of deep freeze, soft freeze, melting freeze, etc. But this basic situation is in place, and it is causing this tension if we do not understand or deal with it clearly. What I think we will see when we try to learn from this situation in the future is that we should try to be consistent in our policies in order to avoid similar stresses in the future. Some modules have been frozen months ago for even smaller changes like a new theme, while others have been granted an exception and are frantically trying to get into shape before the arbitrary deadline. THIS is what is causing this stress, and the whole pointless discussion about calling something a beta or a RC, among others. We all know our releases were not RCs, as they were never intended for release tagging. If we do not analyze this situation and learn from it, we will repeat it in the future releases. My proposal for the future is: pick a schedule, agree on it, and if the project can not make it as a whole, relax it and pick a new one. Rinse, repeat. Only call something a RC when it is really intended for release, for example. Right now, I think that the people that are frustrated because their work did not go in due to the deadlines (like myself) need to take a deep breath, and relax, and let the Plasma and Oxygen people try to finish their vision, until the very last minute. We already granted exceptions to these teams, let them run with them until the release tag. And we will see how it goes. Hopefully there will be only minor issues, we will correct them in 4.0.1, and move on. We may even learn something new from this: maybe we will find out that having last minute rushes really strenghtens the commnity (see the rising number of contributors in panel-devel against the activity in kdegames for example.) Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Discussion about 4.1 timeframe (was Re: What to do about Kompare?)
I'm not. :P You get basically two months to develop and add new features and that's quite crazy. If we do this, you once again leave out KDevelop and kdewebdev from the release because i don't think those are going to be ready in 3-4 months. You also leave out a significantly better version of Kopete since all the new stuff we want to do for that (which is currently planned for 4.1) won't get done either. I'm with Matt here, the same applies to kompare as I doubt everything thats needed can be done in just two months (also looking at the fact that I won't have much time for hacking myself until may). Well, I think that *AFTER* 4.0 it is wrong to continue doing feature-based releases, and we could experiment a bit with schedule-driven ones. If it is 3 or 4 or 6 or 8 months it is open for discussion. But the basic idea is: whenever 4.1 is scheduled for, if a game, or a new Kopete feature, or KDevelop is not ready, then it sits out, and waits for the next round. Simple, easy. People continue to use the existing versions. No loss. Less pressure as well for the developer imo. But if we delay everything because one developer or group will not be able to complete a given feature, then we start penalizing everyone. In this example, to be concrete: if we release 4.1 only in August then I doubt we will be able to keep momentum on the games and perhaps the edu teams as well. We have lots of new stuff waiting on the sidelines: Step for example is wonderful. In games there are several waiting, some for years, like Ksirk. Plasma will probably mature very quickly in 2-3 months following 4.0, I guess, and lots of plasmoids would be ready. KDE 4.0 is a platform release, we need to follow up with incremental upgrades relatively soon imo. If something is not ready, ok! No penalty, nothing is lost. Wait for the next release. But do not hold the gates for things that are ready to be in. The point is that some applications are ALREADY waiting for inclusion since July/07! That is why I think a release in April makes sense, it would have been 9 months after the last chance for inclusion. But it could be in May as well: starting NOW, it would give us at least 3 months for development of these new features. If something can not be done in 3 months, it is doubtful that it would be ready in 4 or 5, at least in the open source world, right? After 4.1, we should probably experiment with the 6 month release schedule that seems to be working for other projects, if we decide that it fits our needs. A disclaimer: if this is going to waste energy, we can delay this discussion to January. The same applies to the Kompare issue: let us follow the path that generates less stress for now, and move on to this 4.0 release. Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Discussion about 4.1 timeframe (was Re: What to do about Kompare?)
Aaron J. Seigo wrote: of course that's what we always used to do. 2.0 and 4.0 have been the only two exceptions i can think of since i've been around the project. Yes, this was something we talked about during last Akademy, when there was the suggestion to move to 6 months cycle. We already have schedule-based releases in the 3.x series, but this methodology is of course not possible on major revamps like 4.0. There is nothing new with this suggestion, I know. It is just the basic idea: for 4.0 onwards it would be better for us to return to this mode of operation. there's also the issue of Qt 4.4 to keep in mind. it will bring a number of significant strides forward that we will likely want to take quick advantage of, and it comes out in Q1 (more towards the end of Q1 than the beginning). That is certainly something to be considered when deciding the schedule. Better yet if we can work in defining a pattern to follow, imo. for certain values of working. for at least one major project, there was an immediate and noticeable decline in both mailing list traffic and commit rates when a 6 month cycle was adopted. Interesting. I wonder if the problem here is the excess of management perhaps? By this I mean that windows to commit new features and work on them are relatively small compared to the window for stabilizing/translating. This is something probably difficult to fine tune, and if we can benefit from what others have learned it is a good way to avoid repeating the same mistakes! i'd sooner see us (loosely) sync along with the Qt dev cycle (which has become much more regular, ~9 month per release) to keep a steady flow of feature / bug fixes going between KDE and Qt. Ok, keeping a pace with Qt actually makes more sense than any other (arbitrary by nature) decision. Also, with 4.0 out, we will resume the cycle of new applications going to playground or maybe kdeapps, and then waiting to be picked for inclusion in the main releases or extragear. This is something we should consider maybe, with feedback from TT. And of course, everything will be magically better after 4.0 is out :) Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: Discussion about 4.1 timeframe (was Re: What to do about Kompare?)
Aaron J. Seigo wrote: If something can not be done in 3 months, it is doubtful that it would be ready in 4 or 5, at least in the open source world, right? i haven't seen that to be the case, no. The half of my brain that almost understands English is confused by this double negative, in answer to my already less-than-clear question :) Do you agree with me, or not? :) Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: [Kde-games-devel] kwin4 rename?
Dirk Mueller wrote: On Tuesday 06 November 2007, Pino Toscano wrote: Alle martedì 06 novembre 2007, Allen Winter ha scritto: Howdy, I'm wondering if the games team would be ok with renaming kwin4 so we reduce some confusion between this fun game and our KDE window manager? I think this question belongs more to the kde-games team (CC'ed). *ping* Martin agreed to the rename, the problem is imo the string freeze. If we can get an exception to do it then we can rename it this Friday. We have a KDE Games team meeting on this Thursday (IRC) and I have added this item to the agenda. To speed up discussion, a short list of names: Konnect4 KonnectFour KAlign4 KFourInLine K4InLine I think I prefer the Four format instead of the numeric 4 as it seems to have less to do with version numbers or something like that. Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: What to do about Kompare?
[EMAIL PROTECTED] wrote: I'm with Matt here, as much as i'd love a kompare on KDE 4.0 we began removing unmaintained games and not allowing new ones in kdegames quite a time ago, actually when the schedule said so, so if we had applied the the same rule to kdesdk, kompare would have been out of KDE 4.0 already months ago. Just to give some context to this, we actually had a deadline for removing unmaintained and unported games in July 2007, according to the initial schedule. And we stick with it, naively :) After that date, nothing as well moved from playground to the module, including games that are mostly done, and we ended up removing more apps in the last couple of months as their state was not great. The effect was that the games module lost some of its momentum, due to our willingness to play by the release schedules. Looking back it was maybe a stupid idea, and we should have continued working on the playground ones, moved them to the module after the deadline, and we would had a tetris and a breakout game for 4.0. Suggestion: for 4.1, I think we should really try to follow the schedules we propose to ourselves. Or break the rules when needed, in a global way for all modules. I understand that not adding Kompare for 4.0 can have an effect on the motivation of the new maintainer, but I can also guarantee you that allowing it to go in (a done deal) also has an impact on some of the members of the games module that will not have their apps in 4.0 because they missed the July cut, and stick by the schedule. To finish, I also think we really need to get this 4.0 thing out, as we are stressing about smaller things almost daily :) Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: new showstopper in kdegames
The click bug in lskat is fixed in revision 74772, no need to revert. Apaku, thanks for finding it. Which reminds me: we (kdegames) really need to do a through check of all applications. A topic for our next meeting, this Saturday. Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
Re: 10 Days Until Next Milestone
I propose a 25 July feature freeze for the sub-module which *really* need it, and keep the 1june for others, like kdegames, to focus on quality (usability, artwork...). At least, some KDE4.0 parts could give a polished image to 4.0, and some frozen dev could even help the latecomer sub-modules to be good enought. Since kdegames is in good shape, I guess they have time left for new features. So freezing the modules that are in good shape seems silly to me now that I think of it. On the other hand, without a module freeze we can not really shift our focus to stabilizing and really finishing all the games. There is always the temptation to rescue that game that did not make the cut for 4.0, and maybe adding that big feature that we know will not be fully matured in the next 150 days or so. I support Johann's idea, of only extending the feature freeze for the modules and apps that really need it. In our case, I guess the proposal made by Allen seems nice: 1. 1 June is changed from new feature freeze to new application freeze 2. We move the feature freeze to the start of the second beta (approx 25 July). As this is also when the string freeze occurs. So each individual game could perhaps use this time to implement a missing feature, but we would not add new games to the module after June 1st. Regards, Mauricio Piacentini ___ release-team mailing list release-team@kde.org https://mail.kde.org/mailman/listinfo/release-team
