-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
All,
The R14 hard freeze in GIT is now lifted for work to start on our first R14-series SRU. R14.0.0 packages are now uploading to the mirror system and we are currently on schedule for a Dec. 15 release.
The nightly build system is currently offline for maintenance. In addition we will be dropping nightly build support for the following Ubuntu versions: Maverick Natty Oneiric Quantal Raring Saucy
This means the nightly builds will be available for the following distributions and versions:
Debian: Squeeze Wheezy Jessie
Ubuntu: Lucid Precise Trusty Utopic Vervet (will come online later)
Going forward, I would like the project to concentrate on the following goals:
1.) R14.0.0 introduced some bugs, bugs that unfortunately were not caught until we were committed to release. We should fix these in mainline ASAP and backport to the SRU branch (r14.0.x) for R14.0.1 release in the next 3 months or so. Bug 2233 is tracking many of these issues as of this writing.
2.) There are a number of style engine problems that still exist as of R14.0.0, some inherited from KDE 3.5.x and some introduced over the years by the TDE project. I will be looking to repair these for the next SRU.
3.) While much of TDE has been brought into XDG compliance there are still a number of areas that are problematic at best. I will be fixing the remaining icon names in mainline as I have time; we also need to be looking into moving to the shared MIME database as our MIME backend. This was made feasible by the recent renaming of the MIME icons to be in line with XDG specifications and the move to libmagic for MIME detection; once complete this should resolve some of the more irritating integration problems between applications like Firefox and the TDE application pool.
4.) Many TDE applications still conflict with their KDE SC counterparts and/or reference KDE directly in their names. A number of these applications (e.g. kdesktop) can be renamed without issue; many cannot (e.g. konsole). Bug 1934 contains additional details; overall the fix is simple and this should be a priority for our next major point release (R14.1.0).
5.) Codebase formatting. While this is not a major problem for the users I have been tripped up more than once by the fact that some portions of the codebase (twin among others) use a vastly different style of indentation and bracing, one that is (IMHO) extremely hard to read and/or modify. This in turn has therefore contributed to many "fix up prior commit" commits and/or outright regressions in GIT. I greatly prefer Stroustrup style formatting with hard tab indentation (no space or combined space/tab indents) and indented public/protected/private blocks. This style is highly legible, emphasizes the control flow, and produces a minimal number of non-whitespace difference lines when an if/else block is modified. All of the new code (thousands and thousands of lines of it) that I have contributed to TDE have been in this style. I have been toying with reformatting the entire TDE codebase in one large commit; if there are no objections I think this step could greatly improve both our development speed and the overall quality of the codebase; comments and discussion are welcome.
6.) Qt3/TQt3 license. While there isn't much we can do about this as the final decision rests in Digia's hands I would like Qt3 released by Digia under at least the LGPL. BSD would be better but I don't know if that's even possible. I have been trying to contact Digia for over a year now (off and on) with no luck getting through to a decision maker; most of my Emails get no response and the rest have ended up on the wrong person's desk. Perhaps if all of the TDE developers contacted Digia separately with the same request they would have to respond? If we can get Qt3 relicensed under the LGPL or BSD licenses it would remove one of the final barriers to TDE adoption.
Doubtless there are other issues that will need to be addressed, some that are not yet even in our bugtracker. Nevertheless, R14.0.0 represents a major step forward for the TDE project as we have successfully modernized large portions of the core codebase and fixed many bugs from the KDE 3.5.x era. I would like to thank our tireless developers for their work and also our users for their support, not only financial but also through time invested via the bugtracker and these lists. TDE would not be possible without you!
Onward we go...
Timothy Pearson Trinity Desktop Project
On 12/12/2014 02:03 AM, Timothy Pearson wrote:
5.) Codebase formatting. While this is not a major problem for the users I have been tripped up more than once by the fact that some portions of the codebase (twin among others) use a vastly different style of indentation and bracing, one that is (IMHO) extremely hard to read and/or modify. This in turn has therefore contributed to many "fix up prior commit" commits and/or outright regressions in GIT. I greatly prefer Stroustrup style formatting with hard tab indentation (no space or combined space/tab indents) and indented public/protected/private blocks. This style is highly legible, emphasizes the control flow, and produces a minimal number of non-whitespace difference lines when an if/else block is modified. All of the new code (thousands and thousands of lines of it) that I have contributed to TDE have been in this style. I have been toying with reformatting the entire TDE codebase in one large commit; if there are no objections I think this step could greatly improve both our development speed and the overall quality of the codebase; comments and discussion are welcome.
Hi Tim, very glad you raised this point, I also wanted to discuss it after the release of v14.0.0. I am an extremely massive supporter of well-styled, well-indented code, to the point that a single line badly indented bothers me. So I fully support the idea of re-styling TDE code.
Now come question 1: what style should be follow? Style is a subjective matter and different people use different style. Therefore I would suggest that you, Slavek, I and Francois discuss a bit about different style guidelines and find one that is fine for all. Probably each of us will have to compromise a bit on that. I will try to come up with some key points to check and later share them with you. This won't be before the week after next, though.
Question 2: once we set on a style, we should have a way to enforce it (something like Lint or equivalent tool). Is there any way we can do that before a git commit is accepted?
Cheers Michele
On Thursday 11 of December 2014 18:03:27 Timothy Pearson wrote:
This means the nightly builds will be available for the following distributions and versions:
Debian: Squeeze Wheezy Jessie
Ubuntu: Lucid Precise Trusty Utopic Vervet (will come online later)
When working on maintenance releases R14.0.x I should to make the same reduction of the supported versions? Or this will be scheduled for the following R14.1.x?
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 2014/12/14 09:19 AM, Slávek Banko wrote:
On Thursday 11 of December 2014 18:03:27 Timothy Pearson wrote:
This means the nightly builds will be available for the following distributions and versions:
Debian: Squeeze Wheezy Jessie
Ubuntu: Lucid Precise Trusty Utopic Vervet (will come online later)
When working on maintenance releases R14.0.x I should to make the same reduction of the supported versions? Or this will be scheduled for the following R14.1.x?
IMO I think it makes sense to follow the same logic. Let's see what Tim thinks as well.
Michele
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA224
On Thursday 11 of December 2014 18:03:27 Timothy Pearson wrote:
This means the nightly builds will be available for the following distributions and versions:
Debian: Squeeze Wheezy Jessie
Ubuntu: Lucid Precise Trusty Utopic Vervet (will come online later)
When working on maintenance releases R14.0.x I should to make the same reduction of the supported versions? Or this will be scheduled for the following R14.1.x?
No, there should be no reduction in distribution support for the life of the R14.0 series. The reduction in support comes into effect for R14.1.
Tim
On Sunday 14 of December 2014 09:33:13 Timothy Pearson wrote:
On Thursday 11 of December 2014 18:03:27 Timothy Pearson wrote:
This means the nightly builds will be available for the following distributions and versions:
Debian: Squeeze Wheezy Jessie
Ubuntu: Lucid Precise Trusty Utopic Vervet (will come online later)
When working on maintenance releases R14.0.x I should to make the same reduction of the supported versions? Or this will be scheduled for the following R14.1.x?
No, there should be no reduction in distribution support for the life of the R14.0 series. The reduction in support comes into effect for R14.1.
Tim
Thank you, just as I also assumed.