corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Test Documents (was RE: Coding Standards page)
Date Thu, 08 Jan 2015 18:07:57 GMT
On 8 January 2015 at 19:04, Peter Kelly <> wrote:

> > On 8 Jan 2015, at 11:52 pm, jan i <> 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.

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
> PGP key: <>
> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966)

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message