All,
My testing of 3.5.13-sru was delayed a bit for, among other reasons, Arch's drop of it's installer and a move to grub2 (kde4'ing of grub...) However, my intent was to test 3.5.13-sru on a completely new machine with no prior installs, etc.. that may skew the results. The bottom line... 3.5.13-sru worked very well on Arch built on all current libs. There were only a few things I missed in packaging (all runtime fixes, no rebuilds required). There were another few cherry picks that we need to include in 3.5.13-sru as well.
The runtime issues were:
- change of Arch init script internals to kdm from tdm - change starttde back to startkde
Cherrypicks needed:
- update the default KDE Components -> File Manager -> 'Preview & Metadata' maximum file size 1.0M -> 10.0M
Other defaults to consider:
- configure subpixel hinting dialog so '[x] Use sub-pixel hinting' is checked by default when 'Use anti-aliasing' is chosen (it is already like that in R14)
- set Launch Feedback - Busy Cursor (Bounding Cursor) 5 sec. + taskbar notification 5 sec.
- get rid of the konqueror (file manager) 'view'-> Configure Background -> Picture. Just set the default to 'Color' instead. Use of a picture kills the alternating row coloration.
- If 3.5.13-sru will be a branch/development branch, then the TDE version should be updated to add the '-sru' designation. Currently it is still just 3.5.13.
Regressions not present in 3.5.13-sru
- kmenu -> settings -> control panel (works) - Applets -> Quicklaunch (no malformed URLs)
I still have a few build issues, but all things considered, 3.5.13-sru works very well. Well done Slavek! I'll post anything else I find.
Next few weeks will be very busy on my end. I will catch up as time permits :)
Dne po 6. srpna 2012 David C. Rankin napsal(a):
- If 3.5.13-sru will be a branch/development branch, then the TDE
version should be updated to add the '-sru' designation. Currently it is still just 3.5.13.
At present already in debian / ubuntu packages I have included "last patch for tdelibs", which changes version from 3.5.13 to 3.5.13.1. To the GIT I want to push it at the time as a final release 3.5.13.1.
Currently the plan is as follows: + Incorporate patches from Francois - see bug 1133 (and some others) + finish "ffmpeg" patch for k9copy - see bug 1119 + finish patch for kmplayer - see bug 1032 + prepare update for package kde-i18n + prepare new package koffice-i18n + now maybe I'm forgetting something :)
Would be nice to have corrected bugs 1079 and 1074. But to 1079 I do not have enough knowledge that I could solve it. And to 1074 now I have not enough time.
Slavek --
On 08/06/2012 12:23 PM, Slávek Banko wrote:
Currently the plan is as follows:
- Incorporate patches from Francois - see bug 1133 (and some others)
- finish "ffmpeg" patch for k9copy - see bug 1119
- finish patch for kmplayer - see bug 1032
- prepare update for package kde-i18n
- prepare new package koffice-i18n
- now maybe I'm forgetting something :)
Would be nice to have corrected bugs 1079 and 1074. But to 1079 I do not have enough knowledge that I could solve it. And to 1074 now I have not enough time.
I agree with the plan 100%. I'll look around and see if there are any others that would be useful for the release. Thank you again for your work here. I really think preserving a Qt3 based/KDE3 compatible TDE branch just strengthens the offerings and legitimacy of the desktop and avoids repeating the mistakes made by kde4 and gnome3 in their all-or-nothing approach. I think Trinity has matured enough as a desktop that we need to formally consider doing this. I would really like to see TDE go forward with 2 offerings: (1) the 14.x development branch providing the innovation and future ideas for TDE; and (2) 3.5.X branch providing the compatible, stable and thoroughly tested enterprise class desktop. At least for the next few years until the R14 branch has a proven track record and can be considered the next proven TDE release.
Both are necessary for the project. This is where other desktops have fallen short and paid the price. Both KDE4 and Gnome3 took the all or nothing approach and the development teams basically abandoned widely accepted and popular desktops. (in gnome's defense, they were at least smart enough to continue maintenance of gtk2). For business, and a large class of general users, stability, usability and compatibility trump the latest gee-whiz, for the one primary reason that matters to them - time/re-training costs and confidence. Others prefer to have the latest and greatest -- and they do so knowing that they will have to commit additional time and resources troubleshooting and re-learning from time-to-time. Both are 100% legitimate approaches to desktop use, but a desktop under heavy development/change can not meet the needs of both.
We have a fantastic opportunity to be able to meet the needs of both if we have the foresight to put a small amount of additional effort into TDE now to set up how we do things to provide a stable and development branches. To a large degree, we have, by natural circumstance, ended up very close to doing just that with R14 and 3.5.13-sru. They are essentially two separate branches of the project that are doing exactly what needs to be done -- provide a development and stable branch for the project. We just need to formalize that in the way we approach development so that we have a mechanism to systematically capture those improvements to R14 that can be candidates for inclusion in the 3.5 branch.
What I would like to see is the project embrace something like that and figure out what, if anything, we need to do now as far as changes, improvements to the GIT tree, Tracker, commit forms, etc. to make this as effortless as it can be in the future. I don't know GIT, commits, etc.., but it seems like it we can do this with a reasonable and justifiable amount of effort. My thoughts would be to:
(1) complete making 3.5.13-sru a top level branch so that it can be checked out just as easily as master/origin with a single git pull.
(2) add a field or checkbox to tracker something like:
[x] Candidate for inclusion in stable branch
(3) then figure out (if possible) how to capture that information when commits are done so that a list of commits that are candidates for inclusion in the stable branch can be returned by query to automate cherry-picking for the branch. (or if we can do it, automate inclusion in the stable branch)
Ultimately it is up to Tim and the rest of the project if we want to commit to something like that. But looking at the benefits something like this offers, and having lived through, and learned from, the blunders by kde4 and gnome3 -- it just seems like a no-brainer to do.
Opportunity knocks only rarely.
-
David C. Rankin -
Slávek Banko