Andrew, I was not advocating ANY "unlimited" access by otherwise unapproved users of your resources.
What I am noting is that some of us do not have access to a sufficiently wide range of environments in order to develop code that "should be expected to work" within the "NEXT" protocol. I will point out that your willingness to run "CMake nightly" runs supporting Kitware is not really different, conceptually, from running "Development Trials" that I might create. In each case, you are "at risk" from any possible intrusions that might accompany submitted tests. I would hope that you are not placing anything more that "CPU cycles" at risk from abuse. What I am seeking is a mechanism to allow "testing" of code BEFORE it is considered ready for "next", etc. Perhaps this needs to be done on a limited "opt-in" basis. Your references to "Workflow" do not, within my quick reading, address the ability to provide testing on an increasing scale over OS, etc. before providing candidates into the more established flows. Richard On Sep 15, 2010, at 7:30 PM, Andrew Maclean wrote: > 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 <rich...@nfsnet.org> > 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 _______________________________________________ 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
