Message: previous - next
Month: May 2018

Re: [trinity-devel] Renaming and split in to official and extra

From: Slávek Banko <slavek.banko@...>
Date: Sat, 26 May 2018 15:59:03 +0200
On Saturday 26 of May 2018 07:30:16 wofgdkncxojef@... wrote:
> Ok, everyone listen.
> I'm proposing to split the programs, in official trinity
> and extra. The list of official packages should be restricted.
> They should be of good enough quality and as a whole should
> be close to the functionality of DE like MATE and xfce. The devs
> should decide upon the list, and then make sure they maintain
> their quality. They should be renamed, with proper names, not
> kdename-trinity, and pulled out of opt. In extra will be everything
> else. The idea is, for the official part to be more appealing to
> distros. If trinity get's in to distros, it will have more exposure and
> get more devs.
> an initial proposal of what the official packages could be:
> all the base system and libs of course
> kdesktop, kicker, tdenetwork manager, tdm, kmix, klipper, control
> center, dolphin, kwrite, kmail, kwallet, kaffeine, konsole, amarok,
> kalculator, gwenview, ark, kpdf other?.
> konqueror is not good enough for a default file manager because of
> it's outdated web browsing component.
> all the above should get proper names, not kdename-trinity
> and moved out of opt. Even the libs, should be renamed something
> like trinity libs, not tqt. The stuff in extra can stay in opt as it
> is. And don't forget, the quality of what will be in the list must stay
> good enough, you can't just shove everything. Once the list will be
> desided, then it will need to be decided how to rename them.
> The whole point of this, is to have something nice, the distros can
> accept taking in. They should not see "Konqueror-trinity" that
> can't render facebook or youtube. The whole point of getting accepted
> by distros, is so that the project gets more exposure and hence more
> devs.

Hi all, wofgdkncxojef,

at begin, I would start with formality. It is good to imagine yourself in 
society at first. Using a very anonymous email with no signature is not a 
very trusted method.

Second: Trinity is simply not just a basic programs, but we have to manage 
the entire 'ecosystem'. That is why we provide a new home for all Trinity 
and old KDE3 applications that our users desire. That's why we provide 
binary packages for a large number of distributions and versions - 
both 'deb' and 'rpm' based. At the same time, it gives us some 
independence from distributions, their goals, their development cycles.

The division of applications into "first category" and "other" I do not 
see as useful. We simply need applications "to be able to compile and 
functional". The fact that some applications get more patches and other 
less patches is a natural way to split applications. At the same time, 
less patches do not indicate that the application is not useful, is not 
used, is not good. It's always about whether users are interested in the 
application and whether someone can contribute by code and find time to 
put their hands on the work.

By the way, one basic division already exists. There are basic packages 
such as tdelibs, tdebase, tdegraphics,... that contain common libraries 
and also some applications, and besides, the application folder that 
contains other applications. Your proposed list of "first category" 
application completely ignores the fact of what part the source code is. 
Are you currently unaware of the source code structure or are you 
suggesting breaking the existing tdebase, tdegraphics,...?

Claiming that a Konqueror is not a good file manager because an outdated 
web component is a bit funny. What is the impact of web component on 
managing local files? We all know that Konqueror is not enough on modern 
websites for the role of the Internet browser. But it does not disqualify 
it from the file manager role.

At different intervals, there is a demand that we need to "rename 
completely everything" to allow become part of official distributions. 
Yes, we are all aware that the conflicting names and the resulting 
location in /opt/trinity is a thing that prevents us from doing so. Yes, 
we all know it would be good to do it. The problem, however, is that a 
renaming of everything is a very challenging task, for which we do not 
have enough time of developers to devote to this. Additionally, here is 
also the fact that renaming will not be beneficial for existing users - 
rather, they will not be delighted. I do not say we do not want to rename 
everything. I just say we prefer other things that seem to be more useful 
for our users.

If there is a strong enough will to prepare a renaming of everything, it 
is appropriate first to prepare a complete list of things to rename and 
their new names. This means not only applications as seen by users but 
also related libraries. And also the names of the objects and the method. 
For example, kate, libkatepart, libkatepartinterfaces, libkateinterfaces, 
libkateutils. As soon as we have a complete renaming plan, we can begin 
to address its implementation.