On 08/16/2012 01:02 PM, Darrell Anderson wrote:

I'll need help to patch the XML parsing. If we get that much fixed then kbugbuster will be in much better shape. I can browse the Trinity bugzilla by bug number but that is all for the moment.

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...

On 08/16/2012 11:02 PM, Darrell Anderson wrote:

I've gone as far as I can with the patch attached to the bug report. I probably could push to GIT. Perhaps you or Slavek want to test in 3.5.13 SRU before pushing to GIT?

I will and I'll report back.

On Friday 17 August 2012 16:05:59 David C. Rankin wrote:

Has anyone pulled the latest kde4 version?

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=1193...

On Thursday 23 August 2012 18:09:29 Slávek Banko wrote:

On Thursday 23 of August 2012 17:52:59 Martin Gräßlin wrote:

...

On Friday 17 August 2012 16:05:59 David C. Rankin wrote:

...

Has anyone pulled the latest kde4 version?

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=11 9

3777&view=markup

When we add to KBugBuster support for new versions of Bugzilla, so no one will defend you to take changes also into KDE4 version of KBugBuster. That will be your choice, as it is our choice to not use KDE4, but to develop the Trinity.

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:

<snip>

...

And no, because it's KDE 3 does not count in this case.

</snip>

Why not? Dragging in a ton of extra libraries just for one small app is not a good idea; in fact if fixing the KDE3 version were not an option I would rather see kbugbuster rewritten for Qt4 only without any KDE dependencies at all.

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.

Then there is the matter of good integration into the desktop environment; this is very difficult to do with two different toolkits and will yield a non-native feel to the resulting application.

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:

An extra dependency is still an extra dependency, and it still consumes disk space (and RAM when the application is running).

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.

...

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.

If you like the (IMHO ugly) Oxygen style, yes. This is sort of like the old Model T argument: you can buy it in any color you want, so long as that color is black.

*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?

...

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.

QtCurve doesn't work on GTK3 and there are no plans to add support at this time AFAIK.

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?)

...

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.

This is NOT justification of a fork. Rather, it is a group of software developers deciding to work on a platform that is more comfortable for them to use. Think about this: with KDE4's vastly superior developer resources and larger userbase, why is the KDE4 version of kbugbuster not being worked on and fixed, whereas TDE is considering fixing its version of the same application? Could it have something to do with the differing styles of computing favored by TDE versus KDE users?.

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 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.

I don't like the arrogance displayed here.

I don't see any arrogance here. Remember that I'm not a native speaker.

...

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.

It was never supposed to be an argument. I don't have time to sit here on the list arguing why TDE is better than KDE or vice versa; I simply brought up some problems that would prevent me from supporting your proposal.

then better don't write anything than bringing arguments you later say aren't arguments after proven wrong.

As an aside, have you noticed that ever since KDE4 came out the Linux desktop has fractured from a KDE- or Gnome- centric experience into many smaller, semi-compatible pieces? Think about that for a bit and ask what might have caused this reaction in the Linux community.

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.

...

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.

And as long as KDE takes the position of being the upstream project instead of merely a collaborator,

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.

a productive relationship between the two projects will be difficult. How would you react if I asked you on a KDE mailing list to develop the TDE version of kbugbuster for us?

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.

I don't think we are responding so much to the technical aspects of your request as we are to your whole attitude. As you probably know, for some time I have been mentioning that we desperately need a new HTML rendering engine, and that we would even consider using WebKit or another Qt4-based rendering engine, as this task would leverage some of the advantages of Qt4 without running into many of its drawbacks. Did you offer to collaborate on integrating KDE's HTML rendering engine into TDE as a plugin? No, you instead come asking us to do your work to enhance software written for a platform we don't use.

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.

Collaboration has its merits, but there has to be mutual respect on both sides for it to work. When will we cease to be the "annoying fork" in your eyes?

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:

Dne pá 24. srpna 2012 Martin Gräßlin napsal(a):

...

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.

Yes, sure, it might be useful to cooperate more. But your first request is always: "Drop the Trinity." Sorry, but this can not be called invitation to cooperation. Until you not change your attitude, so here you only wasted waving with their arguments.

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:

I'm a long-standing user of Gentoo, where the emphasis is on user choice, who used to use KDE 3 , then adopted Fluxbox after the Great Leap Forward. I have no interest in the New Model Desktop, tho' I do use some KDE 4 apps (eg Okular, Gwenview), but want to go on using a couple of KDE 3 apps (Kmahjongg, Kworldview); Trinity offers a possibility of continuing to do that.

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:

On Saturday 25 of August 2012 11:32:31 Martin Gräßlin wrote:

...

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.

Phillip responded to your way of behavior here. Without affecting by your nationality. If such a comparison is for you especially sensitive, you ought to think about it in their behavior here. As I said, until you will not change your approach, it can not be considered as an invitation to cooperation.

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:

Sorry, but your behavior here is always hostile. And this we must accept from you? Sorry, no.

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.

Phillip is not trying to offend you, only give a comparison of your behavior.

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.

It has no sense to continue until you will not change your attitude. As long as you're not respecting our project.

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.

Your words of help are always just empty talk, because they always have first claim "Drop Trinity" (either as a whole or parts). No, this can not be called as a help.

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.

Our projects have a common ancestor - upstream - KDE3. But both of them go on their own way. With a common ancestor have the advantage that they can better collaborate => transfer enhancement between projects. And this is a thing where I see the opportunity to help each other.

good.

For KBugBuster is not our upstream KBugBuster in KDE4 - this is for KBugBuster a dead branch. KDE3 is closest upstream version - and just here we are following up. It will be our pleasure if result then you can take into your branch. But we are talking prematurely, because the result is not yet ;)

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:

On Saturday 25 of August 2012 18:09:55 Martin Gräßlin wrote:

...

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].

Did you look in the log of revisions? http://websvn.kde.org/tags/KDE/4.5.5/kdesdk/kbugbuster/?view=log

"Much younger" according to him does not seem like something substantial.

Qt4 vs Qt3 - yes that is quite a difference. (You can address me as "you" - no need to switch to "him")

I do not know the condition of the referenced student works, but apparently it is a complete rewrite. Not to diminish their value, but to modify the current version KBugBuster are not very usable.

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.

In summary, it seems that we have two practically identical versions KBugBuster - one abandoned in KDE4, and second active in Trinity. I did not find interesting reason why I should prefer to work on a version for KDE4. When they are practically the same, so it will probably be easy to reflect changes from Trinity version to KDE4 version.

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