On Saturday 26 of May 2018 19:13:08 wofgdkncxojef@xxxxxxxxx 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 -- Slávek --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-devel-unsubscribe@xxxxxxxxxxxxxxxxxxxxxxxxxx For additional commands, e-mail: trinity-devel-help@xxxxxxxxxxxxxxxxxxxxxxxxxx Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
