Article:
http://www.datamation.com/open-source/the-fragmentation-of-the-linux-desktop...
End of the first page:
"...Because maintaining and updating the code is a huge effort, and the development team is small, TDE does suffer from more bugs than you may be used to...."
Our release date goal is May 2012, but let's not release R14.0.0 unless all significant blocker, critical, and major bugs are resolved. :)
I would like to ask that we consider point releases when serious bugs need to be backported to a current release. For example, when we need to release R14.0.1 then we build and release new packages. I don't think any of us have been doing that.
Just thinking out loud....
Darrell
Article:
http://www.datamation.com/open-source/the-fragmentation-of-the-linux-desktop...
A point raised by the author is the search by some users for a light weight desktop. Razor-qt is mentioned as well as LXDE. The author believes Xfce no longer fits that category and remains popular largely because of the upstream GTK compatibility with apps.
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.
Just thinking out loud. Again....
Darrell
On Tuesday 17 January 2012 22:42:06 Darrell Anderson wrote:
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!
Lisi
<snip>
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!
Yes, we WANT users! Without users the project would not have attracted the packagers and developers that have greatly assisted and helped in advancing TDE.
Also, more users means more people testing the software. This means that bugs are discovered instead of languishing unfixed for long periods of time.
My opinion: The more users (especially ones that take the time to post on these lists, be it problems, requests, or encouragement), the better!
Tim
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???
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.
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!
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
Personally, as a TDE user, I would like to see a focus on making TDE more polished and more robust. What it doesn't need is feature creep. Some modern niceties, sure, but what brought us back to TDE was a great desktop manager that WORKS. I would like to see it stay that way. If CPU cycles can be freed in the process, GREAT! If not, I don't see CPU's getting any slower.
On Tue, Jan 17, 2012 at 3:27 PM, Darrell Anderson humanreadable@yahoo.comwrote:
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???
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.
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!
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@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@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
Perhaps a package set of one app, the best app, for most uses. Say:
- KControl - KDesktop - Kicker - Konqueror (mostly for file management) - Kopete - Kooka - KCalc - KPDF - Klipper - Kioslaves - KMix - Kolourpaint - Kuickshow - Kaffeine - Kate - Ark - K3b - Konsole
I should be missing some base packages for the desktop system but I think this would be a big starting point. Distros like Gentoo have provided these individual packages for some time now.
Best regards, Tiago
On Tue, Jan 17, 2012 at 11:27 PM, Darrell Anderson humanreadable@yahoo.comwrote:
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???
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.
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!
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@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@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:
Perhaps a package set of one app, the best app, for most uses. Say:
[...]
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".
Le mercredi 18 janvier 2012, Steven D'Aprano a écrit :
Tiago Marques wrote:
Perhaps a package set of one app, the best app, for most uses. Say:
[...]
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
--------------------------------------------------------------------- Hi everybody, hi Steven,
Personally, I find the idea of Steven quite nice, however, the situation in OpenSuse / KDE being what it is today, the software packages for openSUSE KDE3 are to be selected and installed "by hand" by the user via yast: it is extremely painful <troll>, especialy if you dont want a KDE4 library/part to corrupt (-; your installation! </troll>
How about the idea of a "basic" Trinity bundle and another "complete" one, in addition to individual access to each software package?
Cheers Patrick
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
On Fri, 20 Jan 2012, David Hare wrote:
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 don't see kmail, although I do see kaddressbook. kmail is the main reason why I use trinity....
cheers
ant
On 17 January 2012 17:29, Darrell Anderson humanreadable@yahoo.com wrote:
Article:
http://www.datamation.com/open-source/the-fragmentation-of-the-linux-desktop...
End of the first page:
"...Because maintaining and updating the code is a huge effort, and the development team is small, TDE does suffer from more bugs than you may be used to...."
Our release date goal is May 2012, but let's not release R14.0.0 unless all significant blocker, critical, and major bugs are resolved. :)
I would like to ask that we consider point releases when serious bugs need to be backported to a current release. For example, when we need to release R14.0.1 then we build and release new packages. I don't think any of us have been doing that.
Just thinking out loud....
Darrell
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?
Just a thought, Calvon
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?
First, I sent the message to the wrong list. Aargh! :(
Second, the packagers are always the ones who release new packages. All we need is a decision, from Tim or as a team, that certain bug fixes are deemed sufficient to constitute a point release. After such a decision packagers will need to backport any related patches if they so desire. The problem is not manpower, just decisions. :)
Darrell
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?
First, I sent the message to the wrong list. Aargh! :(
Second, the packagers are always the ones who release new packages. All we need is a decision, from Tim or as a team, that certain bug fixes are deemed sufficient to constitute a point release. After such a decision packagers will need to backport any related patches if they so desire. The problem is not manpower, just decisions. :)
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
2012/1/18 Timothy Pearson kb9vqf@pearsoncomputing.net:
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?
First, I sent the message to the wrong list. Aargh! :(
Second, the packagers are always the ones who release new packages. All we need is a decision, from Tim or as a team, that certain bug fixes are deemed sufficient to constitute a point release. After such a decision packagers will need to backport any related patches if they so desire. The problem is not manpower, just decisions. :)
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.
I'd say that better solution might be setting a goal list to be achieved for the next release, instead of date. Like: it will be released when the release goals are met.
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@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@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:
Article:
http://www.datamation.com/open-source/the-fragmentation-of-the-linux-deskto p-1.html
End of the first page:
"...Because maintaining and updating the code is a huge effort, and the development team is small, TDE does suffer from more bugs than you may be used to...."
Our release date goal is May 2012, but let's not release R14.0.0 unless all significant blocker, critical, and major bugs are resolved. :)
I would like to ask that we consider point releases when serious bugs need to be backported to a current release. For example, when we need to release R14.0.1 then we build and release new packages. I don't think any of us have been doing that.
Just thinking out loud....
Darrell
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?
As for running TDE in general (which I have run it exclusive since I finished the arch linux build scripts last month) I have not experienced any breakage etc except for a few things in some of the apps that are minor and I can wait them until someone gets to fixing them so I don't see any big problema with running TDE.
salamat po
On Tuesday 17 January 2012 05:29:33 pm Darrell Anderson wrote:
Article:
http://www.datamation.com/open-source/the-fragmentation-of-the-linux-deskto p-1.html
End of the first page:
"...Because maintaining and updating the code is a huge effort, and the development team is small, TDE does suffer from more bugs than you may be used to...."
Our release date goal is May 2012, but let's not release R14.0.0 unless all significant blocker, critical, and major bugs are resolved. :)
I would like to ask that we consider point releases when serious bugs need to be backported to a current release. For example, when we need to release R14.0.1 then we build and release new packages. I don't think any of us have been doing that.
Just thinking out loud....
Darrell
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?
Usually, yes. However please remember that GIT is unstable in the middle of the development cycle, and that this is *typical* for most projects, FOSS or otherwise.
I have mentioned before that a list of backported patches should be maintained on the Etherpad. Francois Androit has done an excellent job of keeping the RHEL packages updated with backported patches, sadly I am not able to keep up with patching Debian/Ubuntu packages. Help would be appreciated on this front!
R14.0.0 is supposed to be a bugfix release. We have already closed out a lot of bugs on the tracker, so let's keep the patches and fixes rolling in!
Tim
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?
As for running TDE in general (which I have run it exclusive since I finished the arch linux build scripts last month) I have not experienced any breakage etc except for a few things in some of the apps that are minor and I can wait them until someone gets to fixing them so I don't see any big problema with running TDE.
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
On Tuesday 17 January 2012 06:34:22 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?
As for running TDE in general (which I have run it exclusive since I finished the arch linux build scripts last month) I have not experienced any breakage etc except for a few things in some of the apps that are minor and I can wait them until someone gets to fixing them so I don't see any big problema with running TDE.
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
I have only been building the released tarballs. I presently don't have back ported any patches the packages I have made. Since I have not followed what is going on closely I will then wait until the next release.
I am just too busy building my own linux using lfs plus other packages I just don't get the time to say plugged in to what's happening. After I get finished with my distro build I will then have some time to "catch up".
-
ant -
Baho Utot -
Calvin Morrison -
Corey McGuire -
Darrell Anderson -
David Hare -
L0ner sh4dou -
Lisi -
Patrick Serru -
Steven D'Aprano -
Tiago Marques -
Timothy Pearson