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