TDE (dev+stable) Branches [ was Re: [trinity-devel] 3.5.13-sru Testing/Eval -- Good!]

On 08/06/2012 12:23 PM, Slávek Banko wrote: 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.