26 May
2018
26 May
'18
10:13 a.m.
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,...?
You read my list too literally.
It's just an initial sloppy proposal.
All the basic stuff stay in.
Distributions don't want to take in stuff that **seem** not to be
maintained by upstream, they are afraid, they will end up
doing all the support. Their users expect a minimum of quality.
The important word here is ****SEEM****
The split will in practice change nothing for trinity devs.
It just about putting forward a bundle, that trinity devs reasonably
guarantee they will maintain. This way distros will be more open in
taking it in. You already want kdesktop not to crash, you already
want kicker not to crash, you already want sound etc.....
For example, from what i've seen.... kmines seam to work perfectly.
Yet, it will not be included in the official/main bundle, because other
stuff are more important to guarantee they work well enough,
like kdesktop. If kmines is in the main bundle and it brakes, and it's
not fixed, the distros will get very annoyed.
It's like .... i think gstreamer, that splits it's packages in normal,
bad and ugly. Extra doesn't imply they are shit, just that they are
less maintained. Distros want to see maintainers upstream.
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.
Distros will never accept konqueror as is. Dolphin on the other hand,
looks ok. Unless you want to put the effort of either fixing konqueror,
or gutting web browsing out until it's fixed and maintaining a second
unofficial version with konqueror as is for users that want it.
Yea, just give dolphin to the distros, and let users add a repo and install
konqueror them selves.
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.
Properly rename just a small subset of stuff.
Leave the rest in opt, or just give them a very generic rename
like "trinity-oldname". Not renaming, and putting stuff in opt was
stupid to begin with.
Properly renaming stuff, will give the impression to distros that things
are been maintained. Perceptions matter.
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.
Cheers
And this is why i'm starting this discussion.
The whole point of doing this is to get included in distros.
Been included in distros matters. You get more users and more devs.
for your example, leave kate in extra. kate could be renamed as
trinity-kate, then mechanically libtrinity-katepart.....
on the other hand kwrite could become trinity-editor or something like
that. If it uses libkate then maybe libkate should change to something
else too, like libtrinity-editor and still be used by kate and konqueror
and whatever....