--- On Fri, 10/21/11, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
From: Timothy Pearson kb9vqf@pearsoncomputing.net Subject: Re: [trinity-devel] Trinity 3.5.13 Release Date To: trinity-devel@lists.pearsoncomputing.net Date: Friday, October 21, 2011, 11:30 AM
How close is the project to a
3.5.13 release date?
Darrell
Estimated release date is Nov. 1st. Code freeze goes into effect this weekend, barring any major issues.
That's nice to hear!
1. Are there any apps that have not been converted to cmake?
2. Has the wiki been updated/reviewed so newcomers don't get lost building packages? (I have been out of the loop for a long time and I would like to try to build packages soon.)
3. Is 3.5.13 going to include bug fixes or is the conversion to cmake the limit for that release?
Darrell
That's nice to hear!
- Are there any apps that have not been converted to cmake?
The majority have NOT been converted, but the automake build system has been repaired for the remaining apps and therefore works perfectly with the latest versions of Autotools. The main ones that are production ready are:
tqtinterface arts kdelibs kdebase
Others have been converted but I am not using the CMake versions of them in the Debian/Ubuntu builds, so I cannot vouch for completeness/correctness of the build files.
- Has the wiki been updated/reviewed so newcomers don't get lost building
packages? (I have been out of the loop for a long time and I would like to try to build packages soon.)
Calvin, how is our Wiki on this subject? Do you mind putting up some pointers?
- Is 3.5.13 going to include bug fixes or is the conversion to cmake the
limit for that release?
YES! Lots of bug fixes are in SVN; see http://trinitydesktop.org/patches/ for a taste of what is to come.
Tim
On 21 October 2011 21:34, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
That's nice to hear!
- Are there any apps that have not been converted to cmake?
The majority have NOT been converted, but the automake build system has been repaired for the remaining apps and therefore works perfectly with the latest versions of Autotools. The main ones that are production ready are:
tqtinterface arts kdelibs kdebase
Others have been converted but I am not using the CMake versions of them in the Debian/Ubuntu builds, so I cannot vouch for completeness/correctness of the build files.
I can vouch however. I have almost exclusively been building with cmake and it has worked like a charm! :) there may be some small problems with it, but I have not noticed any. In fact we recently just got a patch in for kdeartwork from Fat-Zer, so there is still active progress on it.
- Has the wiki been updated/reviewed so newcomers don't get lost building
packages? (I have been out of the loop for a long time and I would like to try to build packages soon.)
Calvin, how is our Wiki on this subject? Do you mind putting up some pointers?
Well the how to build page should provide good guidance. http://www.trinitydesktop.org/wiki/bin/view/Developers/HowToBuild. The section on cmake should be accurate, just make sure to double check your paths. It is key to keep everything together, so I suggest using our standard /opt/trinity as install prefix.
Excited for the release,
Calvin Morrison
- Are there any apps that have not been converted to
cmake?
The majority have NOT been converted, but the automake build system has been repaired for the remaining apps and therefore works perfectly with the latest versions of Autotools. The main ones that are production ready are:
tqtinterface arts kdelibs kdebase
Others have been converted but I am not using the CMake versions of them in the Debian/Ubuntu builds, so I cannot vouch for completeness/correctness of the build files.
Therefore use cmake for those four packages and automake for all others?
- Is 3.5.13 going to include bug fixes or is the
conversion to cmake the
limit for that release?
YES! Lots of bug fixes are in SVN; see http://trinitydesktop.org/patches/ for a taste of what is to come.
I ask because I submitted many bug reports and most of them remain open. A handful are critical if I am to migrate from KDE 3.5.10 to Trinity. If I had to whittle my list to a few hopefuls for 3.5.13:
293 Kde-config Incorrectly Creates a Profile Folder in the System root directory 388 KDESU Dialog Box Behavior 393 Incorrect kdesu Behavior When Opening Kate 394 Problems with DCOP After Using kdesu 296 New Trinity Profile Error Messages 335 Konqueror Icon Activation Effect 389 Activation Effects 385 Unmounted removable device icons do not appear on the desktop 303 Safely Unmount does not always remove the icon from the desktop 258 ksmserver: Logout confirmation fadeaway is too slow with older hardware
Some or all of these bugs might have been resolved without the developer being aware of a bug report. Building and testing the packages will go far to help and might be the only way to confirm the bug is resolved. I hope to attempt building soon, which is why I started this thread, but did not want to start if development was still in arrears.
Darrell
I ask because I submitted many bug reports and most of them remain open. A handful are critical if I am to migrate from KDE 3.5.10 to Trinity. If I had to whittle my list to a few hopefuls for 3.5.13:
293 Kde-config Incorrectly Creates a Profile Folder in the System root directory 388 KDESU Dialog Box Behavior 393 Incorrect kdesu Behavior When Opening Kate 394 Problems with DCOP After Using kdesu 296 New Trinity Profile Error Messages 335 Konqueror Icon Activation Effect 389 Activation Effects 385 Unmounted removable device icons do not appear on the desktop 303 Safely Unmount does not always remove the icon from the desktop 258 ksmserver: Logout confirmation fadeaway is too slow with older hardware
Some or all of these bugs might have been resolved without the developer being aware of a bug report. Building and testing the packages will go far to help and might be the only way to confirm the bug is resolved. I hope to attempt building soon, which is why I started this thread, but did not want to start if development was still in arrears.
Darrell
Some of the kdesu bugs may have been fixed, but unfortunately no one has had a chance to work on the others AFAIK. We are after all only human, with day jobs and other responsibilities to get in our way. ;-)
I have decided to go ahead with the release in the hopes that the significant improvements may attract more developers, to avoid the project appearing dead, and to allow us to move to GIT (which may also help attract more developers). This release is not perfect by any means, but it is still an improvement overall upon its predecessors.
Tim
I ask because I submitted many
bug reports and most of them remain open. A
handful are critical if I am to migrate from KDE
3.5.10 to Trinity. If I
had to whittle my list to a few hopefuls for 3.5.13:
293 Kde-config Incorrectly Creates a
Profile Folder in the System root
directory 388 KDESU Dialog Box Behavior 393 Incorrect kdesu Behavior When
Opening Kate
394 Problems with DCOP After Using
kdesu
296 New Trinity Profile Error
Messages
335 Konqueror Icon Activation Effect 389 Activation Effects 385 Unmounted removable device icons
do not appear on the desktop
303 Safely Unmount does not always
remove the icon from the desktop
258 ksmserver: Logout confirmation
fadeaway is too slow with older
hardware
Some or all of these bugs might have been resolved
without the developer
being aware of a bug report. Building and testing the
packages will go far
to help and might be the only way to confirm the bug
is resolved. I hope
to attempt building soon, which is why I started this
thread, but did not
want to start if development was still in arrears.
Darrell
Some of the kdesu bugs may have been fixed, but unfortunately no one has had a chance to work on the others AFAIK. We are after all only human, with day jobs and other responsibilities to get in our way. ;-)
I have decided to go ahead with the release in the hopes that the significant improvements may attract more developers, to avoid the project appearing dead, and to allow us to move to GIT (which may also help attract more developers). This release is not perfect by any means, but it is still an improvement overall upon its predecessors.
Tim
Tim, no need to apologize. :) I have not participated in any testing all year because my own schedule prevented that. I predicted that when 3.5.12 was released. My schedule is starting to look like I might again be able to get involved as fall shifts into winter. I might not be able to help before the planned release date but sometime before year's end I expect to be able to help test building packages and test the software in action.
I understand the desire and reasons for releasing even if some serious bugs remain outstanding. That happens with any software project. I expect after the release that key developers will understandably want to disappear and rest for several weeks.
Hopefully thereafter the bug list receives serious attention. That was the plan after 3.5.12 until the shift to cmake happened.
I hope the wiki gets updated for transitioning to GIT. I haven't a clue how to migrate from SVN to GIT or how to keep my local tree current. :)
I look forward to 3.5.13. I continue reading stories about dissatisfaction with KDE 4, GNOME 3, Unity, etc. There are many users who want a full featured traditional desktop and do not want the overhead of KDE 4 or the non-traditional desktops of GNOME 3 and Unity. I believe Trinity will fill a void and will be well received if users believe there is active development.
I suspect reviewers of 3.5.13 will incorrectly compare Trinity to KDE 4. :( I don't know how to handle that misconception, but the 3.5.13 press release should reflect that Trinity is an alternate desktop and is not a competitor of KDE 4. The focus should be on traditional desktops and desktops intended for older and midweight hardware. Perhaps one method to avoid comparisions to KDE 4 is to drop all comments that Trinity is a continuation of KDE 3.5.10. Let Trinity stand on its own merits. Perhaps the 3.5.13 wiki could be posted and everybody involved here can post comments in this list to help ensure users and reviewers understand Trinity when they read the wiki and announcements.
Darrell
Le Fri, 21 Oct 2011 20:22:25 -0700 (PDT), Darrell Anderson humanreadable@yahoo.com a écrit :
- Are there any apps that have not been converted to
cmake?
The majority have NOT been converted, but the automake build system has been repaired for the remaining apps and therefore works perfectly with the latest versions of Autotools. The main ones that are production ready are:
tqtinterface arts kdelibs kdebase
Others have been converted but I am not using the CMake versions of them in the Debian/Ubuntu builds, so I cannot vouch for completeness/correctness of the build files.
Therefore use cmake for those four packages and automake for all others?
- Is 3.5.13 going to include bug fixes or is the
conversion to cmake the
limit for that release?
YES! Lots of bug fixes are in SVN; see http://trinitydesktop.org/patches/ for a taste of what is to come.
I ask because I submitted many bug reports and most of them remain open. A handful are critical if I am to migrate from KDE 3.5.10 to Trinity. If I had to whittle my list to a few hopefuls for 3.5.13:
293 Kde-config Incorrectly Creates a Profile Folder in the System root directory 388 KDESU Dialog Box Behavior 393 Incorrect kdesu Behavior When Opening Kate 394 Problems with DCOP After Using kdesu 296 New Trinity Profile Error Messages 335 Konqueror Icon Activation Effect 389 Activation Effects 385 Unmounted removable device icons do not appear on the desktop 303 Safely Unmount does not always remove the icon from the desktop 258 ksmserver: Logout confirmation fadeaway is too slow with older hardware
Some or all of these bugs might have been resolved without the developer being aware of a bug report. Building and testing the packages will go far to help and might be the only way to confirm the bug is resolved. I hope to attempt building soon, which is why I started this thread, but did not want to start if development was still in arrears.
I have successfully built the dependencies, kdebase and kdelibs checked out from SVN on September 9th on my Slackware64 13.37 system: -Everything is installed into /opt/kde3 prefix -the Qt3 SlackBuild I used is attached; it builds Qt3 cleanly and successfully (I didn't see the problems mentioned by Patrick Volderking in his build script, and kdebase/kdelibs builds and runs). -the poppler-qt3, qca1, qca1-tls SlackBuilds from the kde-3.5.10-for-slack13.0 build well once that the hard-coded path in the qca1-tls build script is updated -the basic global configuration is in the kdeetc3 tarball. This configuration doesn't stop KDE4 from running, and if KDE4 is installed one just has to $ unset KDEDIRS before running Trinity. -for packages from the SVN tree I used a single CMake build script (the "build" file of the tarball).
Darrell
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
- Are there any apps that have not been
converted to
cmake?
The majority have NOT been converted, but the
automake
build system has been repaired for the remaining apps and
therefore works
perfectly with the latest versions of Autotools. The main
ones that
are production ready are:
tqtinterface arts kdelibs kdebase
Others have been converted but I am not using the
CMake
versions of them in the Debian/Ubuntu builds, so I cannot vouch
for
completeness/correctness of the build files.
Therefore use cmake for those four packages and
automake for all
others?
- Is 3.5.13 going to include bug fixes or
is the
conversion to cmake the
limit for that release?
YES! Lots of bug fixes are in SVN; see http://trinitydesktop.org/patches/ for a
taste of what is to come.
I ask because I submitted many bug reports and most of
them remain
open. A handful are critical if I am to migrate from
KDE 3.5.10 to
Trinity. If I had to whittle my list to a few hopefuls
for 3.5.13:
293 Kde-config Incorrectly Creates a Profile Folder in the System root directory 388 KDESU Dialog Box Behavior 393 Incorrect kdesu Behavior When Opening Kate 394 Problems with DCOP After Using kdesu 296 New Trinity Profile Error Messages 335 Konqueror Icon Activation Effect 389 Activation Effects 385 Unmounted removable device icons do not appear on the desktop 303 Safely Unmount does not always remove the icon from the desktop 258 ksmserver: Logout confirmation fadeaway is too slow with older hardware
Some or all of these bugs might have been resolved
without the
developer being aware of a bug report. Building and
testing the
packages will go far to help and might be the only way
to confirm the
bug is resolved. I hope to attempt building soon,
which is why I
started this thread, but did not want to start if
development was
still in arrears.
I have successfully built the dependencies, kdebase and kdelibs checked out from SVN on September 9th on my Slackware64 13.37 system: -Everything is installed into /opt/kde3 prefix -the Qt3 SlackBuild I used is attached; it builds Qt3 cleanly and successfully (I didn't see the problems mentioned by Patrick Volderking in his build script, and kdebase/kdelibs builds and runs). -the poppler-qt3, qca1, qca1-tls SlackBuilds from the kde-3.5.10-for-slack13.0 build well once that the hard-coded path in the qca1-tls build script is updated -the basic global configuration is in the kdeetc3 tarball. This configuration doesn't stop KDE4 from running, and if KDE4 is installed one just has to $ unset KDEDIRS before running Trinity. -for packages from the SVN tree I used a single CMake build script (the "build" file of the tarball).
Darrell
Thanks much. :)
If you are running Trinity SVN on Slackware, which is what I use too (13.1), if you have the time would you run some simple tests on the bugs I listed? I hope to soon start testing the build process again and hopefully thereafter I can more thoroughly test the bugs.
Darrell
Le Sat, 22 Oct 2011 09:02:29 -0700 (PDT), Darrell Anderson humanreadable@yahoo.com a écrit :
- Are there any apps that have not been
converted to
cmake?
The majority have NOT been converted, but the
automake
build system has been repaired for the remaining apps and
therefore works
perfectly with the latest versions of Autotools. The main
ones that
are production ready are:
tqtinterface arts kdelibs kdebase
Others have been converted but I am not using the
CMake
versions of them in the Debian/Ubuntu builds, so I cannot vouch
for
completeness/correctness of the build files.
Therefore use cmake for those four packages and
automake for all
others?
- Is 3.5.13 going to include bug fixes or
is the
conversion to cmake the
limit for that release?
YES! Lots of bug fixes are in SVN; see http://trinitydesktop.org/patches/ for a
taste of what is to come.
I ask because I submitted many bug reports and most of
them remain
open. A handful are critical if I am to migrate from
KDE 3.5.10 to
Trinity. If I had to whittle my list to a few hopefuls
for 3.5.13:
293 Kde-config Incorrectly Creates a Profile Folder in the System root directory 388 KDESU Dialog Box Behavior 393 Incorrect kdesu Behavior When Opening Kate 394 Problems with DCOP After Using kdesu 296 New Trinity Profile Error Messages 335 Konqueror Icon Activation Effect 389 Activation Effects 385 Unmounted removable device icons do not appear on the desktop 303 Safely Unmount does not always remove the icon from the desktop 258 ksmserver: Logout confirmation fadeaway is too slow with older hardware
Some or all of these bugs might have been resolved
without the
developer being aware of a bug report. Building and
testing the
packages will go far to help and might be the only way
to confirm the
bug is resolved. I hope to attempt building soon,
which is why I
started this thread, but did not want to start if
development was
still in arrears.
I have successfully built the dependencies, kdebase and kdelibs checked out from SVN on September 9th on my Slackware64 13.37 system: -Everything is installed into /opt/kde3 prefix -the Qt3 SlackBuild I used is attached; it builds Qt3 cleanly and successfully (I didn't see the problems mentioned by Patrick Volderking in his build script, and kdebase/kdelibs builds and runs). -the poppler-qt3, qca1, qca1-tls SlackBuilds from the kde-3.5.10-for-slack13.0 build well once that the hard-coded path in the qca1-tls build script is updated -the basic global configuration is in the kdeetc3 tarball. This configuration doesn't stop KDE4 from running, and if KDE4 is installed one just has to $ unset KDEDIRS before running Trinity. -for packages from the SVN tree I used a single CMake build script (the "build" file of the tarball).
Darrell
Thanks much. :)
If you are running Trinity SVN on Slackware, which is what I use too (13.1), if you have the time would you run some simple tests on the bugs I listed? I hope to soon start testing the build process again and hopefully thereafter I can more thoroughly test the bugs.
Darrell
293: if I have a root account and run # kde-config --help it creates a .trinity directory. 393: kdesu /opt/kde3/bin/kate doesn't use root settings, tries to use /tmp/kde-guest directories (instead of /tmp/kde-root) but can write to / (so has root privileges). 394: I can reproduce the bug and can add that after kdesu'ing kate, the /tmp/kde-guest/ksycoca belongs to root (!) I could not test immediately other bugs (for exemple, for 258, my compiled Trinity is x86_64…), but if I find the time I can probably correct some of those.
--- On Sat, 10/22/11, /dev/ammo42 mickeytintincolle@yahoo.fr wrote:
From: /dev/ammo42 mickeytintincolle@yahoo.fr Subject: Re: [trinity-devel] Trinity 3.5.13 Release Date To: trinity-devel@lists.pearsoncomputing.net Date: Saturday, October 22, 2011, 7:42 PM Le Sat, 22 Oct 2011 09:02:29 -0700 (PDT), Darrell Anderson humanreadable@yahoo.com a écrit :
- Are there any apps that have
not been
converted to
cmake?
The majority have NOT been converted,
but the
automake
build system has been repaired for the remaining apps
and
therefore works
perfectly with the latest versions of Autotools.
The main
ones that
are production ready are:
tqtinterface arts kdelibs kdebase
Others have been converted but I am not
using the
CMake
versions of them in the Debian/Ubuntu builds, so I
cannot vouch
for
completeness/correctness of the build
files.
Therefore use cmake for those four packages
and
automake for all
others?
- Is 3.5.13 going to include bug
fixes or
is the
conversion to cmake the
limit for that release?
YES! Lots of bug fixes are in
SVN; see
taste of what is to come.
I ask because I submitted many bug reports
and most of
them remain
open. A handful are critical if I am to
migrate from
KDE 3.5.10 to
Trinity. If I had to whittle my list to a
few hopefuls
for 3.5.13:
293 Kde-config Incorrectly
Creates a Profile Folder in the
System root directory
388 KDESU Dialog Box Behavior
393 Incorrect kdesu
Behavior When Opening Kate
394 Problems with DCOP
After Using kdesu
296 New Trinity Profile
Error Messages
335 Konqueror Icon
Activation Effect
389 Activation Effects 385 Unmounted removable
device icons do not appear on the
desktop 303 Safely Unmount
does not always remove the icon from
the desktop 258 ksmserver:
Logout confirmation fadeaway is too
slow with older hardware
Some or all of these bugs might have been
resolved
without the
developer being aware of a bug report.
Building and
testing the
packages will go far to help and might be
the only way
to confirm the
bug is resolved. I hope to attempt building
soon,
which is why I
started this thread, but did not want to
start if
development was
still in arrears.
I have successfully built the dependencies,
kdebase and
kdelibs checked out from SVN on September 9th on my
Slackware64
13.37 system: -Everything is installed into /opt/kde3 prefix -the Qt3 SlackBuild I used is attached; it builds
Qt3
cleanly and successfully (I didn't see the problems mentioned
by
Patrick Volderking in his build script, and
kdebase/kdelibs builds
and runs). -the poppler-qt3, qca1, qca1-tls SlackBuilds from
the
kde-3.5.10-for-slack13.0 build well once that
the
hard-coded path in the qca1-tls build script is updated -the basic global configuration is in the kdeetc3
tarball.
This configuration doesn't stop KDE4 from running, and
if KDE4
is installed one just has to $ unset KDEDIRS before running Trinity. -for packages from the SVN tree I used a single
CMake build
script (the "build" file of the tarball).
Darrell
Thanks much. :)
If you are running Trinity SVN on Slackware, which is
what I use too
(13.1), if you have the time would you run some simple
tests on the
bugs I listed? I hope to soon start testing the build
process again
and hopefully thereafter I can more thoroughly test
the bugs.
Darrell
293: if I have a root account and run # kde-config --help it creates a .trinity directory. 393: kdesu /opt/kde3/bin/kate doesn't use root settings, tries to use /tmp/kde-guest directories (instead of /tmp/kde-root) but can write to / (so has root privileges). 394: I can reproduce the bug and can add that after kdesu'ing kate, the /tmp/kde-guest/ksycoca belongs to root (!) I could not test immediately other bugs (for exemple, for 258, my compiled Trinity is x86_64…), but if I find the time I can probably correct some of those.
Thanks for checking. I know everybody is busy but would be nice if some of these bugs were quashed before release.
Any possibility the official release could be pushed to Nov. 15 and some top/critical bugs get attention?
If not then c'est la vie. Look forward to 3.5.13 anyway. :)
Darrell
<snnip>
Thanks for checking. I know everybody is busy but would be nice if some of these bugs were quashed before release.
Any possibility the official release could be pushed to Nov. 15 and some top/critical bugs get attention?
If not then c'est la vie. Look forward to 3.5.13 anyway. :)
Darrell
If you (or anyone else on this list) can get patches together and uploaded to the bugtracker for any of the bugs mentioned within the next week or so they can go into this release. If not then they will just have to wait I'm afraid--I can't push this release back any further, as it is blocking some rather critical updates that will solve other, more major problems.
Tim
On Sun, Oct 23, 2011 at 10:35 PM, Timothy Pearson < kb9vqf@pearsoncomputing.net> wrote:
<snnip> > Thanks for checking. I know everybody is busy but would be nice if some of > these bugs were quashed before release. > > Any possibility the official release could be pushed to Nov. 15 and some > top/critical bugs get attention? > > If not then c'est la vie. Look forward to 3.5.13 anyway. :) > > Darrell
If you (or anyone else on this list) can get patches together and uploaded to the bugtracker for any of the bugs mentioned within the next week or so they can go into this release. If not then they will just have to wait I'm afraid--I can't push this release back any further, as it is blocking some rather critical updates that will solve other, more major problems.
Forgive me if I missed something on this thread but I'm talking mostly from what I've saw in the most recent SVN releases: isn't it better to postpone due to what may be a lack of polish that might drive away users in the same way KDE 4 and GNOME have done recently? One of the problems I have noticed ever since I started using Linux is that desktop environment teams are extremely preoccupied about release dates more than what users will experience when using said environment, resulting in what ends up as a product in a bug ridden mess that distros have to fix themselves before packaging.
Not doubting your judgement - or anyone's - on the release date, since you better than anyone have a better view of the project as a whole. Could it be in order to have small release updates (call it 3.5.13.1) over the 3.5.13 branch until 3.5.14 is released, in a way to address the bugs that are know to exist currently but can't make the release date? Otherwise they just get pushed further to what can be a good while. That would seem to me a good way to handle this situation.
Best regards, Tiago
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Sun, Oct 23, 2011 at 10:35 PM, Timothy Pearson < kb9vqf@pearsoncomputing.net> wrote:
<snnip> > Thanks for checking. I know everybody is busy but would be nice if some of > these bugs were quashed before release. > > Any possibility the official release could be pushed to Nov. 15 and some > top/critical bugs get attention? > > If not then c'est la vie. Look forward to 3.5.13 anyway. :) > > Darrell
If you (or anyone else on this list) can get patches together and uploaded to the bugtracker for any of the bugs mentioned within the next week or so they can go into this release. If not then they will just have to wait I'm afraid--I can't push this release back any further, as it is blocking some rather critical updates that will solve other, more major problems.
Forgive me if I missed something on this thread but I'm talking mostly from what I've saw in the most recent SVN releases: isn't it better to postpone due to what may be a lack of polish that might drive away users in the same way KDE 4 and GNOME have done recently? One of the problems I have noticed ever since I started using Linux is that desktop environment teams are extremely preoccupied about release dates more than what users will experience when using said environment, resulting in what ends up as a product in a bug ridden mess that distros have to fix themselves before packaging.
Not doubting your judgement - or anyone's - on the release date, since you better than anyone have a better view of the project as a whole. Could it be in order to have small release updates (call it 3.5.13.1) over the 3.5.13 branch until 3.5.14 is released, in a way to address the bugs that are know to exist currently but can't make the release date? Otherwise they just get pushed further to what can be a good while. That would seem to me a good way to handle this situation.
Best regards, Tiago
Our biggest problem is a lack of developer resources. If it were up to me I'd assign a subteam to handle SRUs, but we just don't have that kind of manpower unfortunately. If the 3.5.14 release drags on for an extended period of time then I may have to revisit this decision.
It has been over a year since our last release, and there are significant problems that I can't even begin to fix without seriously breaking the Trinity source for a few months. This could easily push the release date to another year from now--do you really want to use 3.5.12 (which doesn't even compile on modern Linux distributions) until then? ;-)
Believe me I don't like the bugs that are still in the release, but from where I sit this is the best decision. Note that this is not a 3.6.x stable release, it is only an incremental update from 3.5.12.
Tim
On Sun, Oct 23, 2011 at 11:06 PM, Timothy Pearson < kb9vqf@pearsoncomputing.net> wrote:
On Sun, Oct 23, 2011 at 10:35 PM, Timothy Pearson < kb9vqf@pearsoncomputing.net> wrote:
<snnip> > Thanks for checking. I know everybody is busy but would be nice if some of > these bugs were quashed before release. > > Any possibility the official release could be pushed to Nov. 15 and some > top/critical bugs get attention? > > If not then c'est la vie. Look forward to 3.5.13 anyway. :) > > Darrell
If you (or anyone else on this list) can get patches together and uploaded to the bugtracker for any of the bugs mentioned within the next week or so they can go into this release. If not then they will just have to wait I'm afraid--I can't push this release back any further, as it is blocking some rather critical updates that will solve other, more major problems.
Forgive me if I missed something on this thread but I'm talking mostly from what I've saw in the most recent SVN releases: isn't it better to
postpone
due to what may be a lack of polish that might drive away users in the same way KDE 4 and GNOME have done recently? One of the problems I have
noticed
ever since I started using Linux is that desktop environment teams are extremely preoccupied about release dates more than what users will experience when using said environment, resulting in what ends up as a product in a bug ridden mess that distros have to fix themselves before packaging.
Not doubting your judgement - or anyone's - on the release date, since
you
better than anyone have a better view of the project as a whole. Could it be in order to have small release updates (call it 3.5.13.1) over the 3.5.13 branch until 3.5.14 is released, in a way to address the bugs that are know to exist currently but can't make the release date? Otherwise they just get pushed further to what can be a good while. That would seem to me a good way to handle this situation.
Best regards, Tiago
**>
Our biggest problem is a lack of developer resources. If it were up to me I'd assign a subteam to handle SRUs, but we just don't have that kind of manpower unfortunately. If the 3.5.14 release drags on for an extended period of time then I may have to revisit this decision.
It has been over a year since our last release, and there are significant problems that I can't even begin to fix without seriously breaking the Trinity source for a few months. This could easily push the release date to another year from now--do you really want to use 3.5.12 (which doesn't even compile on modern Linux distributions) until then? ;-)
True enough ;)
Believe me I don't like the bugs that are still in the release, but from where I sit this is the best decision. Note that this is not a 3.6.x stable release, it is only an incremental update from 3.5.12.
I had assumed that in some way, given the time it takes to release, it probably would be interesting to do more bug fix releases but probably the versioning could be improved? I mean after all Trinity already supports things that KDE 3.5.10 didn't, like RandR. Have you considered trying to gather some financial support from big distros to hire developers to help, since it seems to be some interest in having Trinity for enterprise related distributions? At least I got the impression that it could be possible to gather some support from what I've read for a few months now.
Best regards, Tiago
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
<snip>
Forgive me if I missed something on this thread but I'm talking mostly from what I've saw in the most recent SVN releases: isn't it better to postpone due to what may be a lack of polish that might drive away users in the same way KDE 4 and GNOME have done recently?
<snip>
Is this "lack of polish" made up of regressions from 3.5.12, or was the same "lack of polish" present in 3.5.12 as well? If the former, then I need to look into it, if the latter, then the release should go ahead as scheduled.
Tim
On Sun, Oct 23, 2011 at 11:08 PM, Timothy Pearson < kb9vqf@pearsoncomputing.net> wrote:
<snip> > Forgive me if I missed something on this thread but I'm talking mostly > from > what I've saw in the most recent SVN releases: isn't it better to postpone > due to what may be a lack of polish that might drive away users in the > same > way KDE 4 and GNOME have done recently? <snip>
Is this "lack of polish" made up of regressions from 3.5.12, or was the same "lack of polish" present in 3.5.12 as well? If the former, then I need to look into it, if the latter, then the release should go ahead as scheduled.
There are some bugs I noticed but I have only compared with KDE 3.5.10. Jabber support in Kopete hasn't been working for me and I've noticed some bugs with KRandR that I need to better understand before filling a bug report. KNetworkManager also needs some bug fixing but it is actually working so that depends on the goals of the project for each release and, as you say, 3.5.12 doesn't compile on current distros, which is very bad.
What's next, 3.5.14 or 3.6?
Best regards, Tiago
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Sun, Oct 23, 2011 at 11:08 PM, Timothy Pearson < kb9vqf@pearsoncomputing.net> wrote:
<snip> > Forgive me if I missed something on this thread but I'm talking mostly > from > what I've saw in the most recent SVN releases: isn't it better to postpone > due to what may be a lack of polish that might drive away users in the > same > way KDE 4 and GNOME have done recently? <snip>
Is this "lack of polish" made up of regressions from 3.5.12, or was the same "lack of polish" present in 3.5.12 as well? If the former, then I need to look into it, if the latter, then the release should go ahead as scheduled.
There are some bugs I noticed but I have only compared with KDE 3.5.10. Jabber support in Kopete hasn't been working for me and I've noticed some bugs with KRandR that I need to better understand before filling a bug report. KNetworkManager also needs some bug fixing but it is actually working so that depends on the goals of the project for each release and, as you say, 3.5.12 doesn't compile on current distros, which is very bad.
What's next, 3.5.14 or 3.6?
Best regards, Tiago
3.5.14 will be next. 3.6.0 should in theory follow that, but it will depend on community support for getting the bugs fixed.
I would appreciate bug reports for any regressions from KDE 3.5.10. Also, knetworkmanager will be going away unless someone steps up to rewrite it for the completely changed NM 0.9 API.
Tim
On Mon, Oct 24, 2011 at 12:53 AM, Timothy Pearson < kb9vqf@pearsoncomputing.net> wrote:
On Sun, Oct 23, 2011 at 11:08 PM, Timothy Pearson < kb9vqf@pearsoncomputing.net> wrote:
<snip> > Forgive me if I missed something on this thread but I'm talking mostly > from > what I've saw in the most recent SVN releases: isn't it better to postpone > due to what may be a lack of polish that might drive away users in the > same > way KDE 4 and GNOME have done recently? <snip>
Is this "lack of polish" made up of regressions from 3.5.12, or was the same "lack of polish" present in 3.5.12 as well? If the former, then I need to look into it, if the latter, then the release should go ahead as scheduled.
There are some bugs I noticed but I have only compared with KDE 3.5.10. Jabber support in Kopete hasn't been working for me and I've noticed some bugs with KRandR that I need to better understand before filling a bug report. KNetworkManager also needs some bug fixing but it is actually working so that depends on the goals of the project for each release and, as you say, 3.5.12 doesn't compile on current distros, which is very bad.
What's next, 3.5.14 or 3.6?
Best regards, Tiago
3.5.14 will be next. 3.6.0 should in theory follow that, but it will depend on community support for getting the bugs fixed.
Great, then whatever bugs are left may be fixed before 3.6 :)
I would appreciate bug reports for any regressions from KDE 3.5.10. Also, knetworkmanager will be going away unless someone steps up to rewrite it for the completely changed NM 0.9 API.
Sure, will do.
Is there something to replace it? I may have a look at that since there's nothing really better than knetworkmanager AFAIK.
Best regards, Tiago
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
<snip>
Is there something to replace it? I may have a look at that since there's nothing really better than knetworkmanager AFAIK.
Gnome's nm-applet is pretty good. Until they release a stable NM API any attempt to rewrite knetworkmanager is just going to waste developer resources.
Tim
On 23 October 2011 21:14, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
<snip> > > Is there something to replace it? I may have a look at that since there's > nothing really better than knetworkmanager AFAIK. >
Gnome's nm-applet is pretty good. Until they release a stable NM API any attempt to rewrite knetworkmanager is just going to waste developer resources.
Tim
+1
Let the Network Manager team settle out the API before we begin to port it. nm-applet is a good applet, has little overhead and will get a big weight off our backs. It integrates well with our gtk integration as well. I think this is the best way to go.
Calvin
On Mon, Oct 24, 2011 at 12:06, Calvin Morrison mutantturkey@gmail.com wrote:
On 23 October 2011 21:14, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
<snip> > > Is there something to replace it? I may have a look at that since there's > nothing really better than knetworkmanager AFAIK. >
Gnome's nm-applet is pretty good. Until they release a stable NM API any attempt to rewrite knetworkmanager is just going to waste developer resources.
Tim
+1
Let the Network Manager team settle out the API before we begin to port it. nm-applet is a good applet, has little overhead and will get a big weight off our backs. It integrates well with our gtk integration as well. I think this is the best way to go.
Calvin
We should be careful though, as 3.4 brings plans to integrate nm-applet + tools into that wonderful shell of theirs.
Le dimanche 23 octobre 2011, Timothy Pearson a écrit :
On Sun, Oct 23, 2011 at 11:08 PM, Timothy Pearson < kb9vqf@pearsoncomputing.net> wrote:
<snip> > Forgive me if I missed something on this thread but I'm talking
mostly
from what I've saw in the most recent SVN releases: isn't it better to
postpone
due to what may be a lack of polish that might drive away users in
the
same way KDE 4 and GNOME have done recently?
<snip>
Is this "lack of polish" made up of regressions from 3.5.12, or was the same "lack of polish" present in 3.5.12 as well? If the former, then I need to look into it, if the latter, then the release should go ahead
as
scheduled.
There are some bugs I noticed but I have only compared with KDE 3.5.10. Jabber support in Kopete hasn't been working for me and I've noticed
some
bugs with KRandR that I need to better understand before filling a bug report. KNetworkManager also needs some bug fixing but it is actually working so that depends on the goals of the project for each release
and,
as you say, 3.5.12 doesn't compile on current distros, which is very bad.
What's next, 3.5.14 or 3.6?
Best regards, Tiago
3.5.14 will be next. 3.6.0 should in theory follow that, but it will depend on community support for getting the bugs fixed.
I would appreciate bug reports for any regressions from KDE 3.5.10. Also, knetworkmanager will be going away unless someone steps up to rewrite it for the completely changed NM 0.9 API.
Tim
--------------------------------------------------------------------- When will the three letters K D E be replaced by "TDE"? When will the project will have only QT in common with KDE? And TDE 2.0 would be better than 3.6, right? I talk when I can not even compile what I downloaded ... And then find the bugs, failing to be able to correct them!
Good luck to everyone Patrick
How is the release to be done.
Will you have a set of tarballs available or a tagged svn release?
I am looking to start building trinity again.... I have devoted my time to finish scratch built linux os, it is booting and I am preparing to build xorg then I will start again trinity.
On Oct 22, 2011 12:45 PM, "scrat" baho-utot@columbus.rr.com wrote:
How is the release to be done.
Will you have a set of tarballs available or a tagged svn release?
I am looking to start building trinity again.... I have devoted my time to
finish scratch built linux os, it is booting and I am preparing to build xorg then I will start again trinity.
We will have tarballs for the release.
hello, i wihs to know if will appears a repo for lenny appart of squeeze, due theres some old machines with large life of trinity desktop instaled in Venezuela/Bolivar
its urgent, if u need too many backported libs, i have a huge repository but no server hosting space on the net..
On Fri, Oct 21, 2011 at 10:34 PM, Timothy Pearson < kb9vqf@pearsoncomputing.net> wrote:
That's nice to hear!
- Are there any apps that have not been converted to cmake?
The majority have NOT been converted, but the automake build system has been repaired for the remaining apps and therefore works perfectly with the latest versions of Autotools. The main ones that are production ready are:
tqtinterface arts kdelibs kdebase
Others have been converted but I am not using the CMake versions of them in the Debian/Ubuntu builds, so I cannot vouch for completeness/correctness of the build files.
- Has the wiki been updated/reviewed so newcomers don't get lost
building
packages? (I have been out of the loop for a long time and I would like
to
try to build packages soon.)
Calvin, how is our Wiki on this subject? Do you mind putting up some pointers?
- Is 3.5.13 going to include bug fixes or is the conversion to cmake the
limit for that release?
YES! Lots of bug fixes are in SVN; see http://trinitydesktop.org/patches/ for a taste of what is to come.
Tim
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messsages on the Web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
In article 99fd35a15ce6d2d84aa5677d46ca781e.squirrel@vali.starlink.edu, Timothy Pearson trinity-devel@lists.pearsoncomputing.net wrote:
How close is the project to a 3.5.13 release date?
Darrell
Estimated release date is Nov. 1st. Code freeze goes into effect this weekend, barring any major issues.
Could I put in a special plea for bugs 552 and 422 please ? Both have patches and I can vouch that both patches work.
Nick
On 22 October 2011 15:55, Nick Leverton nick@leverton.org wrote:
In article 99fd35a15ce6d2d84aa5677d46ca781e.squirrel@vali.starlink.edu, Timothy Pearson trinity-devel@lists.pearsoncomputing.net wrote:
How close is the project to a 3.5.13 release date?
Darrell
Estimated release date is Nov. 1st. Code freeze goes into effect this weekend, barring any major issues.
Could I put in a special plea for bugs 552 and 422 please ? Both have patches and I can vouch that both patches work.
Nick
Tim has fixed them in the SVN.
In article CAJFUHyUF1uyYBreio=cPTWeDiiitek3oyLB8SKKs6nrb+na8Jw@mail.gmail.com, Calvin Morrison trinity-devel@lists.pearsoncomputing.net wrote:
On 22 October 2011 15:55, Nick Leverton nick@leverton.org wrote:
Timothy Pearson trinity-devel@lists.pearsoncomputing.net wrote:
Estimated release date is Nov. 1st. Code freeze goes into effect this weekend, barring any major issues.
Could I put in a special plea for bugs 552 and 422 please ? Both have patches and I can vouch that both patches work.
Nick
Tim has fixed them in the SVN.
I saw the BTS notifications, thankyou very much Tim.
Nick
-
/dev/ammo42 -
Calvin Morrison -
Darrell Anderson -
Nick Leverton -
Patrick Serru -
PICCORO McKAY Lenz -
Robert Xu -
scrat -
Tiago Marques -
Timothy Pearson