Hi All, Speaking for my site regarding point 2, we would be unwilling to allow general external access to our machines. I would suspect most other sites would feel the same way.
>From my viewpoint the process as outlined in http://www.cmake.org/Wiki/CMake/Git seems to work well. The workflow as outlined in http://public.kitware.com/Wiki/Git/Workflow/Topic 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 <[email protected]> wrote: > 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. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Please keep messages on-topic and check the CMake FAQ at: > http://www.cmake.org/Wiki/CMake_FAQ > > Follow this link to subscribe/unsubscribe: > http://www.cmake.org/mailman/listinfo/cmake > -- ___________________________________________ Andrew J. P. Maclean Centre for Autonomous Systems The Rose Street Building J04 The University of Sydney 2006 NSW AUSTRALIA Ph: +61 2 9351 3283 Fax: +61 2 9351 7474 URL: http://www.acfr.usyd.edu.au/ ___________________________________________ _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ Follow this link to subscribe/unsubscribe: http://www.cmake.org/mailman/listinfo/cmake
