Could you raise this on wikitech-l? This was discussed previously there back in September:
http://lists.wikimedia.org/pipermail/wikitech-l/2010-September/thread.html#49425

("Selenium Framework - standard directory for selenium tests")

(In reply to comment #1)

Could you raise this on wikitech-l?

http://lists.wikimedia.org/pipermail/wikitech-l/2010-December/050523.html

There seems to be consensus that the test suites should stay in the SVN download of phase3. It's still up for debate whether the tarbell should include the "tests" directory.

Thanks MZ. Changing the subject to reflect what is still under discussion.

Was any decision made on this? As I recall, it was WONTFIX but since 1.17 is about to come out, maybe it they'll actually be removed from the tarball.

(In reply to comment #5)

Was any decision made on this? As I recall, it was WONTFIX but since 1.17 is
about to come out, maybe it they'll actually be removed from the tarball.

This doesn't make any sense. If there's no firm decision, we should err on the side of keeping the bug open. "WONTFIX" means "we're never, ever going to do this, so stop asking." It doesn't mean "there's no clear decision right now."

Some people like to mark bugs like this as "LATER," but I find that practice rather useless (and somewhat harmful when the bug entries drop off of search results that contain only open bugs). So I'm re-opening this for now.

... Two years later and after moving from SVN to Git: is this still a problem?

(In reply to comment #7)

... Two years later and after moving from SVN to Git: is this still a
problem?

The test suites are still present in the 1.20.3 tarball.

I had removed them from 1.20.0 -- just verified this -- but obviously my changes didn't get put into the tarball-creation scripts.

Is this bug a good candidate for Google Code-in? Modify the tarball-creation scripts not to include test suites?

https://www.mediawiki.org/wiki/Google_Code-In

Download RC2 -- they shouldn't be in there. This should be closed.

If this bug report mentioned the path where to expect these test suites in the tarball, somebody could check with http://download.wikimedia.org/mediawiki/1.22/mediawiki-1.22.0rc2.tar.gz ...

It's reasonable to run test suites on extracted tarballs (e.g. after installing, before the wiki is exposed publicly). This allows checking that the installation is correct, and there are no compatibility problems.

I think it would be better if there were also a tarball version that included the tests.

(In reply to comment #12)

If this bug report mentioned the path where to expect these test suites in
the tarball, somebody could check with
http://download.wikimedia.org/mediawiki/1.22/mediawiki-1.22.0rc2.tar.gz ...

The path is tests, and they are indeed not in that tarball.

Please be sure that the main download advertised to the public does not contain the extra baggage, and only the expert downloads do. Thank you.

Same for those who wish to keep their MediaWiki updated via git -- make sure the main one advertised is cleaner, and only the expert ones contain the extra stuff.

(In reply to comment #16)

Same for those who wish to keep their MediaWiki updated via git -- make sure
the main one advertised is cleaner, and only the expert ones contain the
extra stuff.

Tests are an important part of software development, and it is common to keep them in the same repository as the rest of the code. For MediaWiki in particular, this allows Gerrit reviewers to check that a test is changed/added the same time the application code is, or vice versa.

That means the main core repository will probably continue to hold the tests.

(In reply to comment #16)

Same for those who wish to keep their MediaWiki updated via git -- make sure
the main one advertised is cleaner

Strongly against. Use .gitignore in your checkout.

Well the git download method instructions need to mention how to do that.

(In reply to comment #15)

Please be sure that the main download advertised to the public does not
contain
the extra baggage, and only the expert downloads do. Thank you.

As Matt says in comment 14, stable release don't contain them.

I just checked https://www.mediawiki.org/wiki/Nightlies -- the /tests directory is populated, and I agree with other here that this is A Good Thing.

Including a .gitignore example at https://www.mediawiki.org/wiki/Download_from_Git sounds like a good idea

(In reply to comment #18)

Use .gitignore in your checkout.

This is about creating a .gitignore file e.g. under /core containing e.g. "tests/**", right?

Please confirm. I will edit https://www.mediawiki.org/wiki/Download_from_Git accordingly, and then we can close this bug.

(In reply to comment #20)

(In reply to comment #18)

Use .gitignore in your checkout.

This is about creating a .gitignore file e.g. under /core containing e.g.
"tests/**", right?

I assume you mean the local user doing that, not committing it.

But I don't think gitignore will work for this anyway (gitignore prevents git from adding files by default, or showing them as untracked).

You could do a sparse checkout, but that won't save any bandwidth, so I don't see the benefit.

However, it's not in the tarball, so AFAICT this should be marked fixed.

(In reply to comment #21)

However, it's not in the tarball, so AFAICT this should be marked fixed.

Indeed. Resolving.

Besides, while downloading the extra MBs for /tests in tarballs every other day might become a nuisance to somebody, if you are downloading from git then you will clone once (with the /tests content, and I don't know how could yyou prevent this first download) and from that point syncing /tests in addition to the rest of directories shouldn't be a big deal.