27 Sep
2010
27 Sep
'10
5:46 p.m.
Trinity 3.5.12 is not yet officially released, but I
suspect we now are
close to a serious freeze. I would like to address future plans.
This is
just my rambling.
Correct; the 3.5.12 release is in a little under 4 days so everything
should be finalized at this point.
I have seen conversations about moving to cmake. Then
there is the
tqtinterface support moving toward the goal of being compatible with
qt4.
I presume moving to cmake means all build scripts have
to be revised,
not
to mention all the testing and debugging that follows
such a change. I'm
exhausted with getting build scripts to function in
Slackware, let alone
having to consider starting all over again.
No. My intention is to provide the older Automake system in parallel with
CMake for at least a couple of releases. This will allow time for the
CMake system to stabilize fully, while also permitting Trinity to build on
newer systems. The latter is what makes the CMake conversion so critical;
Automake (and therefore the Trinity build process) has already started to
fail on the latest distributions.
In the short term I hope serious attention is provided
after 3.5.12 to
dramatically reducing the number of existing bug reports and
enhancement
requests.
I agree with this and will address it on-list after release.
I'd like to see 3.5.13 focus solely on the
bugzilla. Possibly too,
resolve
significant bugs and enhancement requests from the
original KDE 3
bugzilla. Apparent to me of late is that the KDE developers
abandoned
3.5.x long before the final 3.5.10 release. The patches committed from
the
Chakra project, Suse, and even Slackware is evidence
of that. Many of
those patches are fairly old and never got merged into the KDE SVN
tree.
I'd like to see cmake and qt4 support scheduled for a subsequent
release.
Can the transition to cmake be scheduled for 3.5.14 or
3.6? New bugs
will
be introduced once the transition to cmake begins,
thereby fattening the
bugzilla. This is what happened with the original KDE
developers. They
always focused on bling and seldom spent serious time adding polish to
what already existed.
CMake support is critical to the continued viability of the project, and
therefore I don't think it can wait. Breakage concerns are minimal, as it
will be provided fully in parallel with the existing build system.
Qt4 support is another matter. Without significant help I honestly don't
see that becoming viable for at least several releases. However, work can
slowly continue on it without the risk of breaking existing software, as
the Qt4 portion of the compatibility layer is completely isolated from the
Qt3 portion.
The release schedule for Trinity does not have to
coincide with Ubuntu
releases. If 3.5.13 focused on bugs and minor enhancments,
3.5.13 could
get released in only two or three months. I think the Trinity schedule
should be independent of Ubuntu.
Not sure here. Ubuntu is a primary consumer of the Trinity project, in
addition to having one of the fastest release cycles (6 months) of the
various distributions Trinity supports. As a result, having the releases
synchronized has worked out fairly well in the past.
Dramatically reducing the bugs and enhancement
requests in 3.5.13 would
provide a nice long-term stable desktop. That then would
provide
breathing
room to migrate to cmake and qt4.
My own hope is 3.5.13 focuses on bugs and minor enhancements, not whole
new
features. That is, add the polish the original KDE devs never added.
Create the stable desktop that KDE 4 isn't.
Working on it! ;-) Remember that unfinished features can be disabled for
release...
Just my $0.02.
Tim