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
Attachments: