+1 The current version of get-started.md lacks introduction into . Today I tried to run a docker container test case "ROOT_DOCKER_DestroyWhileFetching", but by default it's disabled unless I use "sudo make check". I'm not aware of that until I dig into the test environment/filters code.
This kind of information should be included in the "running tests" section of the get started doc. On Fri, Dec 18, 2015 at 4:38 AM, Greg Mann <[email protected]> wrote: > Hey folks! > Something occurred to me recently which is related to the extensive testing > we did in preparation for the 0.26.0 release. Since I started contributing > to the project, my Source of Truth for "how to prepare a given platform to > compile and run Mesos" has been the Getting Started page of our > documentation. However, this doc doesn't provide guidance for all platforms > on "how to prepare this platform to compile Mesos and then TEST it in all > configurations", which is crucial information for us when it comes to > testing, and would be useful to our users as well. I wonder if it makes > sense to have a separate place in our documentation where we include these > exhaustive installation instructions, which may be beyond the scope of a > "Getting Started" document for new users. > > One option is to introduce a new documentation section on testing, where we > can include supplementary installation instructions, as well as information > on the test suite, how to run it, the available options, etc. We already > have a page on good patterns to use when *writing* tests, but nothing I can > find on running the tests, besides a brief mention in "Getting Started". > > Another option would be to just expand our existing install instructions to > be a bit more comprehensive and include instructions for optional > components like libevent2, docker, kernel updates to enable cgroup tests, > etc. Especially on an older platform like CentOS 6.6, this can be tricky. > > Note that some of these installations (like libevent2 on CentOS 6.6) > require the use of hard-to-find RPMs whose origin is uncertain, and it's > possible that we wouldn't want to offer such instructions publicly to our > users. > > Thoughts? > > Cheers, > Greg >
