> 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.... --------------------------------------------------------------------- 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
