[CMake] Questions about the cmake 2.8.3-rc1 release

[Richard Wackerbarth]

Bill,

Some observations on "Dashboard Builds":

As you know, I run a number of FreeBSD builds on the "Nightly" branch.
I had not been running "2.8" builds, etc. because it was unclear if my builds would be of any real value, but only consume my CPU time and increase my electric bill without providing additional information.

My builds are all done on "minimal" installations as an adjunct to my own regression testing. In some respects, they may not represent, and therefore not test, typical end-user environments. 

If adding builds for the 2.8 branch would be of real value, rather than just a waste of my resources, please let me know.

As a "dimension" of builds, it appears to me that the conversion to "git" creates an opportunity to treat all builds in a manner analogous to the "continuous" builds. There, with some minimum wait time, we test to see if anything has changed (in "git" this is a trivial test to see if the branch reference has changed) and run the test suite only if there has been a change.

We could treat "nightly" in the same manner. The "nightly" branch would be thus modified, only by the cron robot, once every 24 hours. The clients, with little overhead, might check for changes every 5 minutes, or every 24 hours, or anywhere in between.

Similarly, the "release candidate" branch might not change for weeks at a time. But for each change, and only upon a change, the clients would "give it a try" without wasting time re-running the test suite on an unchanged source set.

A third topic:

I have been spending some time looking at the issues behind my open "bug" (9825) and have concluded that I could, and to some extent did, write code for the FreeBSD branch that would "work", but concluded that it would be more of a "wart" than a "fix".
IMHO, to do it right,  the CMake code involved should be re-factored so that the best identification strategies can be applied to each, and every, platform. For example, if the "cupid" instructions can be accessed on Intel platforms, EVERY OS should utilize it and use a common decode routine to access the data there available. I am capable of writing such code. However, I do not have the resources to test my code on platforms other that MacOS and FreeBSD. 

I would like to suggest that you consider making available access to additional platforms by:
(1) Finding a representative set of machines, of various configurations and OS, willing to run test suites for development support.
(2) Establishing a mechanism to approve "sandboxes" for the development of a particular idea. I'm sure that you already do this, internally, to some extent. But, I am advocating extending it to external developers and external machine resources (as needed). The idea is to have the testing resources of a wide variety of machines available without the requirement that the code meet the expectations associated with "ready for public trial". Then, when it is ready, the code. so developed, can be submitted to "next" for a through evaluation.

Richard

On Sep 15, 2010, at 4:34 PM, Bill Hoffman wrote:

> On 9/15/2010 4:20 PM, Bill Hoffman wrote:
>> On 9/15/2010 4:08 PM, norulez wrote:
>>> Are there any hopes that the bug 4068 is fixed in the final release?
>>> If not, then in which version?

>> Not at this point. The bug report lacks a test cases. If you were to add
>> a test case, and join the cmake-developer mailing list. Then you can
>> make sure it ends up in the next branch now, so that it can be in the
>> next official release. We are doing releases each quarter, but at this
>> point if it is not a regression and has not been tested in the "next"
>> branch of CMake, it will not be in 2.8.3.