On Sunday 27 May 2018 03:08:08 Sl�vek Banko wrote:
> On Saturday 26 of May 2018 19:13:08 wofgdkncxojef@... wrote:
> > > 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.
>
> I'm going to say that you are missing the awareness of the structure of
> the code and its relationships. Some examples:
>
> Here is the tdelibs source package. From a developer perspective, it's one
> source package, from a distributor's point of view, it's one source
> package but at the same time several binary packages. This package
> contains the TDE base libraries. These are basic things like tdecore,
> tdeui, tdefx, dcop, other things like katepart, tdewallet, tderandr, but
> also other like tdehtml, kjs. Some may have reservations about tdehtm and
> kjs quality. Some may request removal of arts. Others may request of
> renaming Kate. All within one single source package.
>
> Here is the tdebase source package. From a developers perspective, it's
> once again one source package, from a distributor's point of view, it's
> one source package and a many binary packages. In addition to libraries,
> there are applications like tdm, twin, ksmserver, kdesktop, kicker,
> control center, konqueror, kate, klipper, and many more.
>
> So here's one source packages from which distributors should build only
> something like "main", while others would build something else, something
> installed in /usr, something in /opt/trinity. And you want to say that
> nothing would be changed for developers? For users, the result would also
> be interesting because they would get only a portion of TDE contained in
> distributions, while for the remaining parts would have to look again at
> external repositories and hope that it will work together.
>
> If the split should be like tdecore yes, but tdehtm no, kdesktop yes, but
> konqueror no, then it is unrealistic for such division to take place
> within a single source package. I can not imagine how this could work and
> be beneficial to someone.
>
> > > 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.
>
> Sorry, but Dolphin (at least the version from Trinity) certainly can not
> be described as a good replacement for Konqueror as file manager. By the
> way, Dolphin depends on libkonq library... So here again we need to build
> Konqueror.
>
> > > 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 will to do renaming to allow for inclusion in
> distributions, it must be done completely and not just a part. It's the
> same as example above - we've already renamed for example kdecore =>
> tdecore, but are not renamed kded, kjs, kcookiejar - all within same
> source package (tdelibs).
>
> Remember that if, for example, kshell were to be renamed to tde-kshell,
> it's also a renaming with exactly the same level of difficulty. There is
> no difference between "proper" renaming and "partial" renaming.
>
> > > 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....
>
> As I said - we are all aware that renaming is necessary in the long run.
> We also know that this will be a very challenging task. And that we do
> not have enough developers to do this now. This is the simple reason why
> we chose the way to place Trinity to /opt/trinity. This allows us to
> provide Trinity for users without having to immediately do renaming of
> everything.
>
> If you feel motivated enough and you have a lot of persistence, stop
> talking here, put your hands to the work and start working on the list
> for a complete renaming. I recommend to start on
> etherpad.trinitydesktop.org
>
> Cheers

-_- just forget it.