No subject

allows you to work on your code and test it thoroughly before pushing.
When you push check the dashboard after a while to see if there are
any errors. The 'next' branch is reported on the dashboards (the last
time I looked).  At some stage, Kitware will merge next into master.
So I guess next is a kind of sandbox. In this situation, the master
sees only the topics that have been merged into it, It cannot reach
any of the merges into next, so master should remain quite stable.

I hope this helps.

Regards
   Andrew

On Thu, Sep 16, 2010 at 9:26 AM, Richard Wackerbarth <richard at nfsnet.org> w=
rote:
> 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 bu=
ilds 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 therefor=
e not test, typical end-user environments.
>
> If adding builds for the 2.8 branch would be of real value, rather than j=
ust 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 "c=
ontinuous" builds. There, with some minimum wait time, we test to see if an=
ything has changed (in "git" this is a trivial test to see if the branch re=
ference 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 b=
e 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 s=
ource 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 m=
ore of a "wart" than a "fix".
> IMHO, to do it right, =A0the 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 Inte=
l 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 addi=
tional platforms by:
> (1) Finding a representative set of machines, of various configurations a=
nd OS, willing to run test suites for development support.
> (2) Establishing a mechanism to approve "sandboxes" for the development o=
f 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 exter=
nal machine resources (as needed). The idea is to have the testing resource=
s 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 ad=
d
>>> 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.
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/openso=
urce/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmak=
e.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake
>



--=20
___________________________________________
Andrew J. P. Maclean
Centre for Autonomous Systems
The Rose Street Building J04
The University of Sydney=A0 2006=A0 NSW
AUSTRALIA
Ph: +61 2 9351 3283
Fax: +61 2 9351 7474
URL: http://www.acfr.usyd.edu.au/
___________________________________________