On Sunday 27 May 2018 03:08:08 Slávek Banko wrote: > 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 -_- just forget it. --------------------------------------------------------------------- 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
