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, J.D.,P.E.