On 03/04/2011 10:01 PM, Darrell Anderson wrote:
Mostly all I have seen in this list for the past few
months are cmake reports. Nothing about other aspects.
I regularly check the svn patch list. I do not check the bugzilla for resolutions because
I never receive notices the bugs have been patched. Between the two I knew the bugzilla
was receiving very little tender loving care.
When 3.5.13 is released is not as important to me. The effort to quash bugs is important.
I would attempt to build packages for Slackware Current if I saw such serious progress.
I'm not going to build packages when I already know certain bugs will drive me batty
trying to use the system. Nor am I going to offer packages to the Slackware community
knowing such bugs exist and I cannot fix them directly.
I truly wish I could code in C++. I can't. I can compile packages and test build
processes and packages. I doubt Trinity would be in the condition found today for other
distro packagers if we hadn't quashed many, many build process bugs last summer.
I received the distinct impression last autumn that 3.5.13 was going to focus on bug
quashing and cmake and qt4 support would occur in parallel in the background. Hence my
surprise many months later and the reason for my original post.
In my mind, 3.5.13 is a point release and should focus on bugs. The transition to cmake
warrants something more than a point release. Perhaps version 3.6. That way end users know
something significant occurred. If 3.5.13 is not going to be released unless and until
cmake is fully supported, then I suggest not releasing as 3.5.13 but 3.6.
I prefer to see 3.5.13 as the next release and focus on serious bug quashing. That would
allow additional time after the transition to cmake to ensure the new build process works
on all distros. As of 3.5.12, the build process probably works on most distros. Quashing
bugs should not affect that build process. I'll guess that I'll run into some
build problems with Slackware Current, which is three releases beyond 12.2, for which I
built packages. Yet at least we are not introducing new variables into the build process
by moving to cmake. However, last fall when we did this, a significant number of the build
problems were related to not properly including header files and tqt related problems.
Those kinds of build bugs need to be fixed regardless of using automake or cmake.
Darrell
Hi Darrell,
As I mentioned on the list today, we have a major problem already.
Trinity 3.5.12 with Automake just plain *will* *not* *build* on modern
systems, so we are losing a lot of potential help for the bugs every day
that CMake is unfinished. Very few people will purposefully downgrade
(and break) their entire build system just to fix a Trinity bug or two.
Also we cannot release something that is known not to build on 90% of
current Linux distributions. The problem was far more pervasive than I
originally thought, so I had no choice but to block on CMake and bump
its priority to critical.
It's unpleasant I know, but I don't see any other way to do this.
Tim