On 8 January 2015 at 19:07, jan i <[email protected]> wrote: > > > On 8 January 2015 at 19:04, Peter Kelly <[email protected]> wrote: > >> > On 8 Jan 2015, at 11:52 pm, jan i <[email protected]> wrote: >> > >> > I would have assumed that collecting test documents can never be bad. I >> am >> > not sure I can follow you with "to fork or to fetch". >> > >> > I believe we need to documents in our test repo, so that developers >> have no >> > excuse for not running the tests. If I see dftest (and/or dfutil) you >> can >> > setup testcases, that reads the .docx document, generates html, and >> checks >> > it. >> >> I'm in favour of having test documents available in a repository, but I'd >> just add a word of caution about the amount of data involved. I could see >> the test suite potentially reaching several hundred megabytes, and there >> are likely to be situations in which someone wants to just check out the >> source code, not the whole repository. I think I remember running into this >> problem with WebKit once. >> >> Perhaps we could have a separate corinthia-testdocs repository, and add >> that as a git submodule in the main module so that we can ensure the >> references from the source repository are to the appropriate commits in the >> testdocs repository? >> > I like that idea very much...that way we have it available, but not > disturbing our sources. > > I will take a chat with infra, if there are any problems in doing that. > We can have multiple repos, so I am all for a special test repo (I dont understand the part about submodule but never mind).
Next step I quess is to discuss a layout and how we want to use it ? (dennis@ agree on this, or do you see other discussion steps first ?) rgds jan i > > Rgds > jan i > >> >> Currently all the data tests are in a text-based format and easily >> compressed, but if we start adding binary files then space/bandwidth could >> quickly start becoming an issue. Additionally, someone working on one >> particular filter might not want to download 300+Mb of files from other >> filters that their changes are not going to affect. >> >> — >> Dr Peter M. Kelly >> [email protected] >> >> PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key >> > >> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) >> >> >
