Several weeks ago I raised the topic of a Trinity Light. I would like to see some of us explore that possibility. I think if we could offer a light weight version we would significantly increase Trinity popularity. Being able to package a streamlined, light weight set of packages, along with our healthy set of additional apps, likely would raise attention.

The TDE project appears to me to be short of developers, money and other resources already. Would increasing the number of versions help with that???

I also often wonder whether those of us who are simply not capable of helping with the development, aren't just a millstone around the necks of those of you who contribute so much. Do you lot actually *want* users? We seem to me to add nothing other than problems!

We would not release two versions of Trinity. I'm seeking only a team of people to investigate what can be done to create a Trinity Light. What features can be disabled during the compiling process? Which Control Center settings can be changed? Etc. The goal is to create a wiki article about creating Trinity Light. Who actually releases such a version is something downstream packagers and users decide. As a close friend often would quip, those are the kinds of problems we want to have. :) Basically, more users should mean more developers too. But if not, more users is still a good thing. :) Darrell --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help(a)lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

Tiago Marques wrote: [...] Speaking as a user, I really dislike the KDE practice of packaging applications in bundles. The package manager (yum or apt-get or similar) should handle dependencies, for everything else, individual applications (or application suites, like KOffice) should get individual packages. If I want to install Konsole, I should be able to "apt-get install Konsole" rather than "apt-get install bundle-of-17-apps-I-don't-want-and-1-I-do". -- Steven

It should not be difficult to create a new "TDE-light" metapackage. Trouble is identifying the existing "metapackages" responsible for the bloat, which has always been a downside of KDE. I spent quite a bit of time on that, the aim was functionality without bloat. Previous discussion on this subject (mailing list archive): "minimal trinity installation (14 Nov 2011 12:19:22)" http://trinity-users.pearsoncomputing.net/?0:201111 Not much interest at that time. This is my current package list for a "TDE Light" but quite functional (as opposed to minimal, which just kdebase will do). It will give a Squeeze installation of little over 2GB. It is what I used for the Exe GNU/Linux +TDE live-cd, which squashed to under 700MB. I stripped out all the unnecessary metas I could find and started looking at unnecessary deps and recommends of some packages (e.g. kaffeine, soundkonverter) Remove any you don't want, but watch out that what you add is not another monster meta. (and check what the "recommends" are) ########################### kdebase-trinity amarok-trinity ark-trinity gwenview-trinity gtk-qt-engine-trinity k3b-trinity k3b-data-trinity kaddressbook-trinity kcalc-trinity karm-trinity kate-plugins-trinity kcoloredit-trinity kcron-trinity kde-core-trinity kde-i18n-engb-trinity kde-i18n-es-trinity kde-style-qtcurve-trinity kdeaddons-kfile-plugins-trinity kdeartwork-trinity kdeartwork-emoticons-trinity kdeartwork-misc-trinity kdeartwork-style-trinity kdeartwork-theme-icon-trinity kdeartwork-theme-window-trinity kdebase-kio-plugins-trinity kdeeject-trinity kdegraphics-kfile-plugins-trinity kdelibs-trinity kdelibs-data-trinity kdemultimedia-kfile-plugins-trinity kdf-trinity kdiff3-trinity kdirstat-trinity kdm-trinity libkcddb1-trinity libtqt3-integration-trinity kregexpeditor-trinity kget-trinity kghostview-trinity kicker-applets-trinity kio-locate-trinity kipi-plugins-trinity kmix-trinity knemo-trinity knotes-trinity konq-plugins-trinity konqueror-trinity konversation-trinity kpdf-trinity kpowersave-trinity kscreensaver-trinity kscreensaver-xsavers-trinity ksensors-trinity ksnapshot-trinity ksplash-engine-moodin-trinity ksvg-trinity ktorrent-trinity kuser-trinity kwin-style-crystal-trinity --no-install-recommends kaffeine-trinity --no-install-recommends soundkonverter-trinity

I think one of the problems is manpower.I think we all agree that SRU releases are good. Backporting bugs and such. The problem is manpower. Maintainers are however free to update their distros with patches - instead of official SRU that would require creating new tarballs and a whole hell of update related issues. Why doesn't someone ( maybe you :p) create a tarball of all the patches to be applied. Then email it to the different maintainers?

Darrell is correct.  I would like to wait until Feb. 1st and see where the TDE codebase is before deciding if a point release is a good idea.  If majority of the bugs have been fixed by then I would suggest moving up the R14.0.0 release date and skipping the point release.  If not, a point release will most likely be needed.

Packagers: you can help with this by maintaining a list on the Etherpad of backported patches that have been included in your distributions' 3.5.13 packages.  This will make it easier for the TDE team to weigh the cost and benefit of each patch when the point release decision is made. Tim --------------------------------------------------------------------- To unsubscribe, e-mail: trinity-users-unsubscribe(a)lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help(a)lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting

On Tuesday 17 January 2012 05:29:33 pm Darrell Anderson wrote: Just replying out loud..... I can see that some of the comment from datamation maybe is waranted. For me the fustration is building a package from git repo say tdebase on a monday then working on several other packages and then update the local git repo rebuilding tdebase on friday results in tdebase not building at all. Possibility due to a commit/patch/update in the source. I have since abandoned building from git and only use the 3.5.13 tarballs which have worked well for me. My question is before a commit is made does whoever changed/updated/patched/crunched/mutilated the code, first see if it builds without barfing/puking then do the commit?

GIT is not the same as an official release. I expect GIT to break occasionally. That's okay. Backporting patches to an official release is not the same as backporting all changes in GIT since the official release. Those types of patches would be extracted from GIT and made available as separate patches. I would guess before any official point release anouncement that at least three packagers from different distros would test the backporting, both from a build and usability perspective. Darrell