On 08/16/2012 01:02 PM, Darrell Anderson wrote: I too would like to see kbugbuster working well. I'm don't know XML, but I'll see if I can find where it is done in the code... -- David C. Rankin, J.D.,P.E.

On 08/16/2012 11:02 PM, Darrell Anderson wrote: I will and I'll report back. -- David C. Rankin, J.D.,P.E.

On Friday 17 August 2012 16:05:59 David C. Rankin wrote: there is no latest kde4 version [1]. The bugzilla interface changed too much, kbugbuster just does not work with later versions of bugzilla [2]. I would be surprised if the Trinity version of kbugbuster works with the Trinity bugzilla. If it works, then I would highly recommend to update your bugzilla installation (as in that case it would have severe security issues). Btw. these are the things were a closer interaction between KDE and Trinity would help. Instead of long discussions and trying to fix it, the relevant information could have easily been gathered. It would be so awesome if Trinity could concentrate on the things that matter and stop forking everything and the kitchen sink. I still hope that we can unfork Trinity. Oh yeah and in case you really want to fix kbugbuster it would be super awesome if you would take up the kde 4 version and work upstream instead of a fork. Best Regards Martin Gräßlin [1] http://websvn.kde.org/tags/unmaintained/4/kbugbuster/ [2] http://websvn.kde.org/tags/unmaintained/4/kbugbuster/version.h?revision=119…

On Thursday 23 August 2012 18:09:29 Slávek Banko wrote: From what I understand in this thread you want to improve KBugBuster. That's awesome because there is no community aroung KBugBuster anymore. I have been hoping that someone would pick up KBugBuster and make it work with new Bugzilla versions for years. Now what I do not understand is that if there are people who want to work on it, why they need to fork and why they have to use an outdated version as the start point of the fork? Could you please explain me the reason why the Trinity project had to fork KBugBuster? Please give me an explanation I understand and which provides some very good reasoning why it is more important to work against each other than to work together. And no, because it's KDE 3 does not count in this case. What exactly in KBugBuster was so bad that the KDE 3 source base had to be forked? Best Regards Martin Gräßlin

On Thursday 23 August 2012 13:55:05 Timothy Pearson wrote: You see these are the points which I so-much dislike about the Trinity fork: the fork is based on wrong assumptions. Please do your homework about the "ton of extra libraries" especially in the light of Frameworks 5. Now I will get back as an answer that a KDE 4 application will pull in evil Nepomuk and much more evil Akonadi which in turn pulls in the most evil of all called MySQL. And I will have to tell you for the felt 100th time that none of these are a required dependency for a KDE application. And even if what is so bad about an extra dependency? Can someone explain that please? And if you try to do so, please also think about the current cost of disk space (according to Wikipedia 3.5¢/GB in 2011) and RAM doesn't matter as an app only pulls in what it really links anyway. right, like not seeing any difference between GTK2, GTK3 and KDE applications [1]. What a surprise: KDE is the only environment having matching GTK2 and GTK3 styles. Oh and then there is the Plastique widget style shipped by Qt which is just the same as the one used in KDE 3. And there's of course qtcurve [2] offering matching styles for KDE 3, 4 and GTK. I find it a really, really sad thing to bring look as a justification of a fork. It just illustrates how ridiculous this whole thing is. Please think about it. Regards Martin [1] http://hugo-kde.blogspot.de/2011/04/taste-of-things-to-come.html [2] http://kde-look.org/content/show.php?content=40492

On Thursday 23 August 2012 15:47:35 Timothy Pearson wrote: I think I asked in my previous mail why that is a problem. Let me check: "And even if what is so bad about an extra dependency? Can someone explain that please? And if you try to do so, please also think about the current cost of disk space (according to Wikipedia 3.5¢/GB in 2011) and RAM doesn't matter as an app only pulls in what it really links anyway." So could you please elaborate on that. I really want to understand it. *sigh* it was you telling that it looks different if used two toolkits and that this is a reason to have a fork. Now I showed you that you can have a style which looks exactly the same on three different toolkits. Basically I prooved your argument being wrong. What's your reply: it's ugly. Seriously? What's that for an argument? First of all it's completely irrelevant in the discussion and second of all it's highly subjective. Who cares what you think a style looks like? and what has that to do with the discussion? You said that two toolkits (KDE 3 and 4) are bad because they look different. I show you a toolkit supporting KDE 3, 4 and GTK and your answer is it does not support GTK3. Seriously? What's that for an argument? Is KBugBuster nowadays written in GTK 3 that it matters? And even if I consider that this would be a valid argument, where is the Trinity GTK 3 style? (I can play as badly as you and twisting arguments, that's fun isn't it?) yeah the old "KDE doesn't care about its users argument". Easy to repeat and hardly to contradict because you have thousands of examples where KDE does not care about the users. So you asked me to think about it. And the first thing I noticed is that you obviously did not think about it, because then you would have realized that the targeted usergroup of kbugbuster are not users but KDE developers. You can realize that by the fact that it lives in kdesdk for one thing, then that it is a tool to manage bugs, but not to report bugs and so on. So the targeted user groups the KDE developers do not care about is themselves. Now what could be reasons that the KDE developers do no longer care about KBugBuster? Most likely because nobody sees a motivating factor to work on it. Maybe it is because web-applications are more common today for usage than when KBugBuster was initially written (think about Facebook and co). Maybe the Internet connections are nowadays better, so that you don't need an offline application to work with a bugtracker (IIRC KBugBuster still uses the email interface to bugzilla instead of xml/json web client). Maybe it's because bugzilla's webinterface is nowadays really good and does not suck badly requiring a desktop application. I really think and hope that KDE and Trinity could collaborate. To make it quite clear only Trinity would benefit from a closer collaboration. From a KDE standpoint I could as well relax and wait till the annoyance of the fork has died away. But to get to a closer collaboration the Trinity developers have to start to improve their relationship with KDE. Don't assume everything KDE does is bad. Just look at your users argument above and how ridiculous it is in the given context. It doesn't need me to realize that this has been a ridiculous argument, you could have done as well while writing it. As long as Trinity developers bring up ridiculous justifications for their fork there cannot be a collaboration. As long as Trinity bring in arguments which are clearly wrong and harmful to the KDE community by spreading FUD (nothing else the users argument is) the fork while be perceived as an enemy and that is nothing the Trinity developers can want. So I kindly ask you to take a step back from what you do and think about it. It's not pure chance that I chimed in the thread about KBugBuster to ask for the reason to work on the fork instead of working upstream. Best Regards Martin Gräßlin

On Friday 24 August 2012 08:57:32 Timothy Pearson wrote: I don't see any arrogance here. Remember that I'm not a native speaker. then better don't write anything than bringing arguments you later say aren't arguments after proven wrong. Right, I agree there is a lot of forking going on. So let's have a look at the situation. Recently The-H had an article about it[1]. First of all Canonical and Red Hat do not really like each other. That caused the Unity vs. GNOME Shell split. Which meant GNOME split in two. Then there was the situation that GNOME Shell and Unity released in a slightly too early point of time. People started to fork GNOME twice, once as MATE, once at Cinnamon. As both forks are by the same people (Linux Mint) I tend to consider them as one. The fork MATE was clearly not needed as the GNOME Panel is even still part of GNOME Shell (fallback mode). Cinnamon is in my opinion rather unfortunate as most of it could have been achieved just as extensions to GNOME Shell instead of forking. Personal opinion: it's a marketing stance by the Linux Mint team. They gained some popularity by doing all the forks. Currently on number one of distrowatch, but what does this count? People using Ubuntu have no idea about distrowatch index, so what. So the big question is what does the forks mean for the projects. For this question to answer we actually need proper data, which is difficult to gather. Possible sources are the 2011 Linux Questions Member Choice Awards, but again we have to consider that Ubuntu users do not know anything about Linux Questions Member Choice Awards. Given the target audience of such questionaires one can expect the uncommon desktop environments to be stronger. Looking at the data for best desktop environment [2] we see that Cinnamon and Mate together are not even reaching LXDE. Trinity just has one percent while KDE is a strong winner with 33 % which is actually a pretty bad result for KDE. A more recent questionaire [3] with more participants does not list Trinity at all but KDE 3 is at 0.5 %. Mate and Cinnamon are also not listed, but "Other" get 16 %. KDE has more than twice as much votes than any other desktop in this competition. Another questionaire by the German speaking page pro-linux [4] also confirms the data set with KDE 3 being at 2 % and KDE at 42 %. The GNOME forks are again not listed, but others reach 7 %. So although we cannot get correct numbers for users we clearly see a trend of KDE gaining some benefit from the mess around GNOME. But still the data shows that there is lots of buzz around nothing. The number of users "lost" to the forks is marginal. how would you call KDE in this case? I consider it as an upstream to trinity because KDE code has flown down to the Trinity project. I am a very strong user of the upstream and downstream words and don't see how it could be harming for collaboration. Qt considers KDE as both an upstream and a downstream and the collaboration is so excelent that at Akademy in the keynote about the Qt project the KDE collaborators were not listed as the borders are blurring. Well the first thing I can answer here is that there is no "us" and "they". As far as I understand you forked the KDE code base, so "your" code is actually KDE code (which is something you should more often think about). Now if someone would come to my mailing list and ask me to work on the fork of my application I would immediatelly contact the community working group and do everything possible to prevent the fork and harm being done to the community. Remember it's you that forked KDE software and not the KDE community which forked Trinity. That I as a KDE developer come to the people who forked my application and ask to stop the fork is more normal than those who forked coming to the forked application. And I really deeply believe that the fork has to stop and that there is ground to work together instead of against each other. Huh? You never asked me whether I would want to work on it. Well my answer would be that I use Firefox and are happy with it, so I don't have an interest in KHTML or WebKit. Apart from that I would also tell you that my distribution is no longer providing Qt3 which makes it impossible for me to develop for Trinity. Now on a technical level I would tell you to just use the KWebKitPart [5] inside Tonqueror as it's done by Konqueror. Please don't twist my words. I did not call Trinity an "annoying fork", but wrote the "annoyance of the fork", which is quite a difference. The one is describing the project the other the situation. Now I find it strange that I as a non-native speaker have to tell you about such subtle differences. The current situation is in my opinion an annoyance because it's harmful for KDE as the fork is not trying to work together even if you ask them. Furthermore the fork is spreading FUD about KDE like the "not caring about users". As long as these things are happening and the project is harming my work, yes as long as that the situation is an annoyance to me. Best Regards Martin [1] http://www.h-online.com/open/features/Comment-Desktop- Fragmentation-1662354.html [2] http://www.linuxquestions.org/questions/2011-linuxquestions-org-members- choice-awards-95/desktop-environment-of-the-year-919888/ [3] http://pollator.com/polls/which-linux-desktop-environment-are-you-using [4] http://www.pro-linux.de/umfragen/2/95/welche-desktop-umgebung-nutzen-sie- ueberwiegend.html [5] https://projects.kde.org/projects/extragear/base/kwebkitpart

On Friday 24 August 2012 17:52:42 Slávek Banko wrote: Which is nothing I have ever written. Yes I asked you to drop the fork of KWin and I gave good arguments for that. And yes I will continue to ask you to drop ridiculous forks like the one to KWin. What would I like to see the Trinity project being? Well a project which is not a fork. No application which is still developed by KDE should be forked without a good reason why a fork is needed. So far these reasons nobody was able to present here. And even if there were a reason to fork it should always be in the interest of all parties to overcome the fork. I think there is a great possibility to collaborate if Trinity is no longer a fork but just about the "retaining the overall KDE 3.5 computing style". Keep KDesktop/Kicker and co, those things which got displaced and help making the KDE software which you think need improvements rock instead of forking. Working together instead of against each other. I am happy to help you there to find a way back to the KDE community, to unfork. If you are interested I am happy to further outline a possible plan which will benefit Trinity (and not KDE). Remember: forks are nothing good. So am I asking much if I ask you to drop the forking? I think no, I think it would be a good and important step for Trinity to no longer be a fork. Think about it. Think about the applications you forked and for each ask yourself what has been the reason to fork it. Think about whether it's helping your users. Think about whether it's on the long time the best solution for the users. Think about whether the energy put into the fork would have better helped the application to fix the reasons for the fork. Trinity developers always claim that they care about the users. So do that, think whether e.g. providing KWin 3 is caring about your user, whether that is really the best window manager you can offer. And if you come to arguments which are based on the bad experience of early KDE 4.x versions, think about if the argument still holds when comparing with 4.8 or 4.9. Step aside from what you are doing. Question your own deeds. Question the assumptions you have. I have seen many wrong assumptions here on the mailing list. Things like Qt 4 developed for smart phones. Throw over bord all your assumptions or at least verify that they are true. If you did benchmarks throw them away because they are biased (you did the benchmark after all). So with the words of IBM: THINK! Best Regards Martin P.S. I don't want to see any reply to this mail in the next 24 hours. Please take the time to think about what I have written and think about the points I have outlined to think about.

On Saturday 25 August 2012 04:43:04 Philip Webb wrote: You completely support what I write and suggest without noticing it :-) I don't want Trinity to fork things like kpdf which evolved into Okular. I don't want Trinity to fork Gwenview which is much better in the current variant. I want Trinity to continue the work on the applications which got dropped or displaced (e.g. Kicker or KWorldView) to work on a future together instead of against each other. I want that the users get the best possible software. In case that the KDE software is better (e.g. Okular) there should not be a fork of the inferior version. Btw. a KDE version of kmahjongg [1] exists. Oh and it would greatly help if everybody would calm down a little bit. Comparison to 3rd-World dictators should not happen on a mailing list. Surprised that KDE people don't like Trinity, if they get compared to dictators if they try to collaborate? Well I'm not. Btw. comparing a German person with dictators is the worst insult you could imagine for a German. Best Regards Martin Gräßlin P.S. an apology for what you just wrote would be appropriate. [1] http://games.kde.org/game.php?game=kmahjongg

On Saturday 25 August 2012 13:45:27 Slávek Banko wrote: Sorry no! Insulting people is completely unacceptable - everywhere. Don't justify such anti social behavior. I have not insulted anyone here. All I have done in this thread was to ask why you work on the fork of KBugBuster instead of working with your upstream. It's especially completely unacceptable to insult people coming here trying to help you. Realize that! I try to help you! It's not the first time that I have been insulted on this list and probably won't be the last time. And people don't stand up against such anti social behavior. Completely unbelievable. I have been involved in many online communities, but none would accept such behavior. Stand up against the people damaging your project. Insulting people is unaccaptable, no matter if they are KDE or Trinity developers. Regards Martin

On Saturday 25 August 2012 15:41:40 Slávek Banko wrote: I am not hostile to you. I am trying to improve the situation of the fork. Yes part of that includes to unfork to make Trinity acceptable to the KDE community. Please realize that I am basically the only one of the KDE project reaching out to Trinity. I want the communities to be one community. I want to overcome the hostile situation we are in caused by the Trinity fork. You know that KDE developers consider the fork performed as Trinity as hostile? You know that developers asked you to change names as they don't want that people think that its the same product? You know that many KDE developers are very concerned about the drop of quality? You know that many KDE developers fear that Trinity destroys the reputation of KDE 3? You know that many KDE developers feel it's an affront that Trinity devs talk about the KDE version which they have not developed as "their" app? If it is a hostile act to ask you to rethink your forking strategy because you don't have the manpower to cary out the tasks previously done by hundreds of developers by a little bit more than a dozen, then sorry, then I'm hostile. well if comparing a person with a dictator is not an offense, well then I have a different understanding of offensive talk. Btw. it does not matter that it was not meant offensive (we don't know that because Philip has not replied yet), it only matters how the person being insulted feels about it. A simple sorry, was not meant that way clears matters up. Your project? Keep in mind that the code of your project has been written by the KDE community. But well you wanted respect for Trinity. I applaud any effort to keep Kicker/KDesktop (the KDE 3 "desktop computing") alive. I know and acknowledge that there are users disliking KDE Plasma. I would love to have something I could offer them to use. That is what I would love Trinity to provide. That is what I am interested in to see. That is why I contacted the Trinity team in the first place. But at the moment I cannot tell users disliking Plasma to use Trinity, because it includes forks of everything and the kitchen sink where KDE just has the better products. Think of KWin, Kate, Krita and so many more excellent KDE applications where the KDE 3 version is just on a different level. Then there is the problem that I cannot tell users to use Trinity because it uses EOL-ed libraries like Qt 3. I have done my Computer Science Master degree at a Chair for Computer Security. I just cannot recommend anyone to use unmaintained libraries which are security relevant. And that's just a pity. But you see I have an interest in Trinity. I hope that is enough shown respect. Think about whether its help or not. My first contact with this mailinglist was to ask you to use KWin instead of your fork, because you have not been able to maintain the window manager. I have shown you wrong commits, I have later on reviewed code to the fork. I offered you to get a well maintained codebase instead of something you have no expertise on. Well I call that help even if it includes dropping part of your fork. Want a list of bugs reported against KDE 3 and fixed in 4.9? Recently I have told you here in this thread that KBugBuster has been dropped from KDE and given you the reasons which you were unaware about. I think that's already quite some help. good. No you are wrong. KBugBuster used to be part of KDE-sdk till 4.5 - which is two years ago. Much younger than the 3.5 version Trinity forked. Also there had been some work which has not been finished going on by some students to be found in [1]. Best Regards Martin [1] http://websvn.kde.org/branches/work/kbugbuster-isi/KBugBuster-v2/

On Saturday 25 August 2012 19:03:31 Slávek Banko wrote: Qt4 vs Qt3 - yes that is quite a difference. (You can address me as "you" - no need to switch to "him") think about it. One of the reasons (to my knowledge) to restart the work is that KBugBuster builds up on a very old way to interact with Bugzilla. Maybe that is in the time of a JSON interface not the smartest thing to do. Look for example at [1] how handy it can be to interact with Bugzilla through the JSON API in combination with QJson. Well I cannot tell you what to do but do you really want to work on a Qt 3 version? The other thing is that you probably want users, right? How large is the target audience for a Qt 3 app (remember my distribution - Debian testing - no longer shipps Qt 3) compared to a Qt 4 app? With a nice Qt 4 based Model/View approach its even possible to write apps for smartphones (I would love to be able to manage bugs from my smartphone - have to think about that). Last but not least think about the impact it could have if someone from the Trinity project approaches the KDE community with some work done on KBugBuster and asking for re-inclusion into the KDE-sdk. That could change the complete view on the Trinity project. Would anyone notice that work went into the forked KBugBuster? Unlikely. Of course it's your decision on what to work. But if I had the chance to use the code which has been ported over to Qt 4 already, I would not think twice. Especially not if there are no other differences. Best Regards Martin [1] http://quickgit.kde.org/index.php?p=scratch%2Fgraesslin%2Fchangelog- generator.git&a=summary