Hi.
I filed bug 26259, "MediaWiki bloated with test suites": https://bugzilla.wikimedia.org/show_bug.cgi?id=26259
RobLa asked me to send an e-mail to wikitech-l about this bug. It's my view that checking out MediaWiki from SVN should not include files that most users do not need or want. These test suites seem to fit perfectly within this category.
MZMcBride
On 06/12/10 15:56, MZMcBride wrote:
Hi.
I filed bug 26259, "MediaWiki bloated with test suites": https://bugzilla.wikimedia.org/show_bug.cgi?id=26259
RobLa asked me to send an e-mail to wikitech-l about this bug. It's my view that checking out MediaWiki from SVN should not include files that most users do not need or want. These test suites seem to fit perfectly within this category.
Do you mean you don't want them in phase3? Subversion is really the only place for such files, but we have in the past moved large files out of phase3 to reduce the size of core checkouts, specifically /trunk/artwork.
-- Tim Starling
Tim Starling wrote:
On 06/12/10 15:56, MZMcBride wrote:
I filed bug 26259, "MediaWiki bloated with test suites": https://bugzilla.wikimedia.org/show_bug.cgi?id=26259
RobLa asked me to send an e-mail to wikitech-l about this bug. It's my view that checking out MediaWiki from SVN should not include files that most users do not need or want. These test suites seem to fit perfectly within this category.
Do you mean you don't want them in phase3? Subversion is really the only place for such files, but we have in the past moved large files out of phase3 to reduce the size of core checkouts, specifically /trunk/artwork.
Yes, sorry. I follow the instructions at "Download from SVN" typically to install MediaWiki.[1] I ran 'svn up' on two hosts today and noticed a lot of additions of files in the maintenance directory, none of which should be in there, in my view.
I don't think anyone has an issue with these tests being in Wikimedia's SVN repo, but putting them in the maintenance directory that end users checkout seems unnecessary and wasteful.
MZMcBride
On 12/6/2010 12:07 AM, MZMcBride wrote:
Tim Starling wrote:
On 06/12/10 15:56, MZMcBride wrote:
I filed bug 26259, "MediaWiki bloated with test suites": https://bugzilla.wikimedia.org/show_bug.cgi?id=26259
RobLa asked me to send an e-mail to wikitech-l about this bug. It's my view that checking out MediaWiki from SVN should not include files that most users do not need or want. These test suites seem to fit perfectly within this category.
Do you mean you don't want them in phase3? Subversion is really the only place for such files, but we have in the past moved large files out of phase3 to reduce the size of core checkouts, specifically /trunk/artwork.
Yes, sorry. I follow the instructions at "Download from SVN" typically to install MediaWiki.[1] I ran 'svn up' on two hosts today and noticed a lot of additions of files in the maintenance directory, none of which should be in there, in my view.
I don't think anyone has an issue with these tests being in Wikimedia's SVN repo, but putting them in the maintenance directory that end users checkout seems unnecessary and wasteful.
I think better time would be spent decoupling all the languages. Out the 57 megs for an svn export, 41 is the languages directory. Distribute the Big $foo, where $foo is some reasonable number of major languages, and offer the rest as a seperate dl.
On 6 December 2010 08:11, Q overlordq@gmail.com wrote:
I think better time would be spent decoupling all the languages. Out the 57 megs for an svn export, 41 is the languages directory. Distribute the Big $foo, where $foo is some reasonable number of major languages, and offer the rest as a seperate dl.
This suggestion seems to come up from time to time. I feel it is unrealistic. First of all we can't remove them from svn, since they have to be there. We could remove them from the tarballs, but please, last time I checked the tarball was hardly over 12 megs. Even with very slow modem it should take an hour at most to download that. Using better compression algorithm would likely shrink it as much as removing few languages. The minor languages don't even take as much space as the major languages, which usually have more complete localisation.
Drawing the line is not easy and would likely cause continuous, unnecessary contention, put some languages in a privileged position and hurt MediaWiki's top notch i18n and l10n support. Each language is special, but you don't see that if you just look at the number of speakers. Do we really want hurt one of our greatest advantages?
Besides, it feels silly to talk about this, while we simultaneously talk about including some of the most common extensions in the name of providing feature complete MediaWiki straight from the box--which is a goal I agree with.
-Niklas
Niklas Laxström wrote:
Besides, it feels silly to talk about this, while we simultaneously talk about including some of the most common extensions in the name of providing feature complete MediaWiki straight from the box--which is a goal I agree with.
I wouldn't say it's silly. If a very large percentage of MediaWiki installations will end up installing ParserFunctions, but a very small percentage of MediaWiki installations will end up using an obscure message file, there's a reasonable debate there about which to include. A somewhat similar metric is sometimes used when determining whether a feature should go into core or into an extension.
Speaking of extensions, there's now a bug about bundling ParserFunctions with MediaWiki: https://bugzilla.wikimedia.org/show_bug.cgi?id=26261 Tim has asked developers who support (or oppose, I guess) this idea to comment on that bug.
MZMcBride
On Dec 6, 2010, at 5:12 AM, Niklas Laxström wrote:
On 6 December 2010 08:11, Q overlordq@gmail.com wrote:
I think better time would be spent decoupling all the languages. Out the 57 megs for an svn export, 41 is the languages directory. Distribute the Big $foo, where $foo is some reasonable number of major languages, and offer the rest as a seperate dl.
Perhaps an option would be to remove them from phase3, and moving them to a separate directory. Then, if someone switches the wiki language to some obscure language, or does &uselang=dfdjdkgj, or other activity that needs an obscure language, it would run a one-time download to the local filesystem. Might be too slow, but it's only a 1 time download.
Just an idea.
-X!
Hi!
MediaWiki is famous because its almost supported in all languages that's something other wiki software don't have, lets not try to remove that. So I think the main bundle should be mediawiki with *all* languages.
But a other option is to add a second download option where people can download mediawiki with only EN and make tarballs for all languages available so people can add the languages they want. Maybe something that can be done on a mirror site.
Huib
2010/12/6 Soxred93 soxred93@gmail.com
On Dec 6, 2010, at 5:12 AM, Niklas Laxström wrote:
On 6 December 2010 08:11, Q overlordq@gmail.com wrote:
I think better time would be spent decoupling all the languages. Out the 57 megs for an svn export, 41 is the languages directory. Distribute the Big $foo, where $foo is some reasonable number of major languages, and offer the rest as a seperate dl.
Perhaps an option would be to remove them from phase3, and moving them to a separate directory. Then, if someone switches the wiki language to some obscure language, or does &uselang=dfdjdkgj, or other activity that needs an obscure language, it would run a one-time download to the local filesystem. Might be too slow, but it's only a 1 time download.
Just an idea.
-X! _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
* Huib Laurens sterkebak@gmail.com [Mon, 6 Dec 2010 12:46:53 +0100]:
Hi!
MediaWiki is famous because its almost supported in all languages
that's
something other wiki software don't have, lets not try to remove that. So I think the main bundle should be mediawiki with *all* languages.
Preservation of minor languages is a good idea. Besides that, one might disagree which language is minor and which is not.
But a other option is to add a second download option where people can download mediawiki with only EN and make tarballs for all languages available so people can add the languages they want. Maybe something that can be done on a mirror site.
That is widely used approach in desktop software, "localized versions" of software. Dmitriy
On Mon, Dec 6, 2010 at 6:46 AM, Huib Laurens sterkebak@gmail.com wrote:
But a other option is to add a second download option where people can download mediawiki with only EN and make tarballs for all languages available so people can add the languages they want. Maybe something that can be done on a mirror site.
I don't think this is a good idea. People will opt for the smaller download if given a choice, and then their users won't be able to switch their interface language.
Offhand suggestion: can we pack/compress the language files in a way that keeps them smaller on the server but leaves them usable?
-- brion On Dec 7, 2010 10:42 AM, "Aryeh Gregor" <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com> wrote:
On Mon, Dec 6, 2010 at 6:46 AM, Huib Laurens sterkebak@gmail.com wrote:
But a other option is to add a second download option where people can download mediawiki with only EN and make tarballs for all languages available so people can add the languages they want. Maybe something that can be done on a mirror site.
I don't think this is a good idea. People will opt for the smaller download if given a choice, and then their users won't be able to switch their interface language.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Tue, Dec 7, 2010 at 10:07 PM, Brion Vibber brion@pobox.com wrote:
Offhand suggestion: can we pack/compress the language files in a way that keeps them smaller on the server but leaves them usable?
-- brion
I thought about that yesterday. Even if we compress them, they are 11 MB in gzip and 6.5 MB in LZMA as far as I remember.
And it will not decrease the distribution size for apparent reason.
--vvv
* Victor Vasiliev vasilvv@gmail.com [Tue, 7 Dec 2010 22:12:58 +0300]:
On Tue, Dec 7, 2010 at 10:07 PM, Brion Vibber brion@pobox.com wrote:
Offhand suggestion: can we pack/compress the language files in a way
that
keeps them smaller on the server but leaves them usable?
-- brion
I thought about that yesterday. Even if we compress them, they are 11 MB in gzip and 6.5 MB in LZMA as far as I remember.
And it will not decrease the distribution size for apparent reason.
It will decrease the size of installation, at least. And there are probably more of installations than distributives. Dmitriy
Brion Vibber wrote:
Offhand suggestion: can we pack/compress the language files in a way that keeps them smaller on the server but leaves them usable?
-- brion
We can provide them gzipped and require them with compress.zlib:// prepended to the filename. That will work magically™ as far as the zlib extension is enabled (which almost always will be the case). We can perform the same magic with bzip2 but it may be a less frequent extension.
Niklas Laxström wrote:
This suggestion seems to come up from time to time. I feel it is unrealistic. First of all we can't remove them from svn, since they have to be there. We could remove them from the tarballs, but please, last time I checked the tarball was hardly over 12 megs. Even with very slow modem it should take an hour at most to download that. Using better compression algorithm would likely shrink it as much as removing few languages. The minor languages don't even take as much space as the major languages, which usually have more complete localisation.
Drawing the line is not easy and would likely cause continuous, unnecessary contention, put some languages in a privileged position and hurt MediaWiki's top notch i18n and l10n support. Each language is special, but you don't see that if you just look at the number of speakers. Do we really want hurt one of our greatest advantages?
Besides, it feels silly to talk about this, while we simultaneously talk about including some of the most common extensions in the name of providing feature complete MediaWiki straight from the box--which is a goal I agree with.
-Niklas
A few days ago the issue came up where I was talking with an end user who was complaining about MediaWiki being too large (in the server, not in the tarball) compared to other apps like wordpress. I think there's a use case for providing a mediawiki download where the end user can check which languages they want and provide a custom download. And/or document how to strip some languages from mediawiki.
It probably would not be too hard to make an extension to do just that. Just modify ExtensionDistributor.
-X!
On Dec 6, 2010, at 10:02 AM, Platonides Platonides@gmail.com wrote:
Niklas Laxström wrote:
This suggestion seems to come up from time to time. I feel it is unrealistic. First of all we can't remove them from svn, since they have to be there. We could remove them from the tarballs, but please, last time I checked the tarball was hardly over 12 megs. Even with very slow modem it should take an hour at most to download that. Using better compression algorithm would likely shrink it as much as removing few languages. The minor languages don't even take as much space as the major languages, which usually have more complete localisation.
Drawing the line is not easy and would likely cause continuous, unnecessary contention, put some languages in a privileged position and hurt MediaWiki's top notch i18n and l10n support. Each language is special, but you don't see that if you just look at the number of speakers. Do we really want hurt one of our greatest advantages?
Besides, it feels silly to talk about this, while we simultaneously talk about including some of the most common extensions in the name of providing feature complete MediaWiki straight from the box--which is a goal I agree with.
-Niklas
A few days ago the issue came up where I was talking with an end user who was complaining about MediaWiki being too large (in the server, not in the tarball) compared to other apps like wordpress. I think there's a use case for providing a mediawiki download where the end user can check which languages they want and provide a custom download. And/or document how to strip some languages from mediawiki.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On Mon, Dec 6, 2010 at 10:02 AM, Platonides Platonides@gmail.com wrote:
Niklas Laxström wrote:
This suggestion seems to come up from time to time. I feel it is unrealistic. First of all we can't remove them from svn, since they have to be there. We could remove them from the tarballs, but please, last time I checked the tarball was hardly over 12 megs. Even with very slow modem it should take an hour at most to download that. Using better compression algorithm would likely shrink it as much as removing few languages. The minor languages don't even take as much space as the major languages, which usually have more complete localisation.
Drawing the line is not easy and would likely cause continuous, unnecessary contention, put some languages in a privileged position and hurt MediaWiki's top notch i18n and l10n support. Each language is special, but you don't see that if you just look at the number of speakers. Do we really want hurt one of our greatest advantages?
Besides, it feels silly to talk about this, while we simultaneously talk about including some of the most common extensions in the name of providing feature complete MediaWiki straight from the box--which is a goal I agree with.
-Niklas
A few days ago the issue came up where I was talking with an end user who was complaining about MediaWiki being too large (in the server, not in the tarball) compared to other apps like wordpress. I think there's a use case for providing a mediawiki download where the end user can check which languages they want and provide a custom download. And/or document how to strip some languages from mediawiki.
I agree that we could provide smaller tarbells for downloading a release.
I do not agree with moving them in SVN though.
-Chad
On 6 December 2010 17:02, Platonides Platonides@gmail.com wrote:
Niklas Laxström wrote: A few days ago the issue came up where I was talking with an end user who was complaining about MediaWiki being too large (in the server, not in the tarball) compared to other apps like wordpress. I think there's a use case for providing a mediawiki download where the end user can check which languages they want and provide a custom download. And/or document how to strip some languages from mediawiki.
How hard can it be? find languages/messages/ -name "Messages*.php" -and -not -name "MessagesEn.php" -delete Or use some fancy graphical ui to do the same.
What comes to the tarball.. 8,0M mediawiki-1.16.0.7z 13M mediawiki-1.16.0.tar.gz
This is very simple to implement with no big downsides (we can continue providing both formats).
And here's the same with all message files stripped out: 2,0M mw-lite.7z 2,8M mw-lite.tar.gz
It might look cool, and someone can provide those if he wants, but I think the default release tarball should contain all languages.
-Niklas
Niklas Laxström wrote:
On 6 December 2010 17:02, Platonides wrote:
Niklas Laxström wrote: A few days ago the issue came up where I was talking with an end user who was complaining about MediaWiki being too large (in the server, not in the tarball) compared to other apps like wordpress. I think there's a use case for providing a mediawiki download where the end user can check which languages they want and provide a custom download. And/or document how to strip some languages from mediawiki.
How hard can it be? find languages/messages/ -name "Messages*.php" -and -not -name "MessagesEn.php" -delete Or use some fancy graphical ui to do the same.
I don't know. Aren't the message files referenced from somewhere?
I strongly disagree with removing tests from the /trunk/phase3 directory. They should be there, though they may be thrown out on the release. Maybe introduce a "production" branch where the phase3 is mirrored without development stuff?
--vvv
On Mon, Dec 6, 2010 at 10:08 PM, Victor Vasiliev vasilvv@gmail.com wrote:
I strongly disagree with removing tests from the /trunk/phase3 directory. They should be there, though they may be thrown out on the release. Maybe introduce a "production" branch where the phase3 is mirrored without development stuff?
Too much work IMO.
I think the easiest solution is to just tweak the make-release script to exclude the tests directory (wherever we end up putting it).
-Chad
* Chad innocentkiller@gmail.com [Mon, 6 Dec 2010 22:11:19 -0500]:
On Mon, Dec 6, 2010 at 10:08 PM, Victor Vasiliev vasilvv@gmail.com wrote:
I strongly disagree with removing tests from the /trunk/phase3 directory. They should be there, though they may be thrown out on
the
release. Maybe introduce a "production" branch where the phase3 is mirrored without development stuff?
Too much work IMO.
I think the easiest solution is to just tweak the make-release script to exclude the tests directory (wherever we end up putting it).
One can even imagine that some subset of tests might be performed after the completion of installation, to verify it. As for rare languages, text messages have good compression ratio, the distribution may originally have rare language file compressed with gzip and unpacking it on demand, when there is first attempt to load this particular language. Dmitriy
On 07/12/10 04:11, Chad wrote:
I think the easiest solution is to just tweak the make-release script to exclude the tests directory (wherever we end up putting it).
It might be handy to get the test suites deployed on as many hosts as possible. This would let users run the test right out of the box and might help us fixing bugs later.
Just my 2 cents.
On Tue, Dec 7, 2010 at 12:44 PM, Ashar Voultoiz hashar+wmf@free.fr wrote:
On 07/12/10 04:11, Chad wrote:
I think the easiest solution is to just tweak the make-release script to exclude the tests directory (wherever we end up putting it).
It might be handy to get the test suites deployed on as many hosts as possible. This would let users run the test right out of the box and might help us fixing bugs later.
I'm not set one way or the other on including them in the default download archive. If we do, that's ^^^ the way to do it though.
If we do go that route, we should additionally package the tests for those that would like to download them.
-Chad
On 06/12/10 05:56, MZMcBride wrote:
I filed bug 26259, "MediaWiki bloated with test suites": https://bugzilla.wikimedia.org/show_bug.cgi?id=26259
RobLa asked me to send an e-mail to wikitech-l about this bug. It's my view that checking out MediaWiki from SVN should not include files that most users do not need or want. These test suites seem to fit perfectly within this category.
I have at least two objections :
- I want to be able to commit a bug fix + associated tests in one revision without having to fetch the whole phase3 tree. It is much easier to track and phase3 has many stuff I do not care about.
- Users fetching from SVN are most probably interested in development and will *require* the test suites. Regular user use the tarballs which can be build without the tests suite though.
Can't you just ignore the test suites ?
I do not care about squid support or utf-normalisation. Should they get moved out of trunk as well?
Ashar Voultoiz wrote:
On 06/12/10 05:56, MZMcBride wrote:
I filed bug 26259, "MediaWiki bloated with test suites": https://bugzilla.wikimedia.org/show_bug.cgi?id=26259
RobLa asked me to send an e-mail to wikitech-l about this bug. It's my view that checking out MediaWiki from SVN should not include files that most users do not need or want. These test suites seem to fit perfectly within this category.
I have at least two objections :
- I want to be able to commit a bug fix + associated tests in one
revision without having to fetch the whole phase3 tree. It is much easier to track and phase3 has many stuff I do not care about.
I don't commit to Wikimedia's SVN repo, so I won't comment on this.
- Users fetching from SVN are most probably interested in development
and will *require* the test suites. Regular user use the tarballs which can be build without the tests suite though.
I don't think it's reasonable to say that most users downloading from SVN are interested in development, though some certainly are. SVN is convenient for installations and upgrades. That's certainly why I use it. Even if we could say that most users downloading from SVN are interested in development, I don't see how that extends to saying that test suites are required for development. You've lost me.
The maintenance directory has maintenance tools in it. I don't think test suites fall within the category of "maintenance." Like large artwork files, these seem to be "development" tools that shouldn't be downloaded with every phase3 checkout.
Can't you just ignore the test suites ?
Sure, and I do. But I don't imagine that this "tests" directory will get any smaller with time. I don't really want to see MediaWiki get more bloated over time with files that very few people will want or need. If that applies to other parts of phase3 as well, those ought to be examined and considered in separate bugs and threads (the "math" directory is a prime target, for example).
I do not care about squid support or utf-normalisation. Should they get moved out of trunk as well?
Perhaps, but that's an issue for a different bug and a different thread. :-)
MZMcBride
MZMcBride z@mzmcbride.com writes:
Even if we could say that most users downloading from SVN are interested in development, I don't see how that extends to saying that test suites are required for development. You've lost me.
If a developer breaks a test, ze[1] should fix it. As the tests cover more and more of the code, the tests should be considered more integral to development since they provide a nice sanity check on any changes a developer is likely to make.
The maintenance directory has maintenance tools in it. I don't think test suites fall within the category of "maintenance." Like large artwork files, these seem to be "development" tools that shouldn't be downloaded with every phase3 checkout.
Others have already pointed out that this argument could be applied to other areas of the phase3 tree, but let me add this.
If you measure the size of everything under phase3 and normalize it against the size of the maintenance/tests directory[2], you come up with following:
1.000 maintenance/tests/ 1.263 resources 1.302 skins 3.964 maintenance 14.949 includes 25.818 languages
That is, the tests directory is only 1/4 of the size of the entire maintenance directory. The includes directory is almost 15 times larger than the tests directory and, yes, languages tops them all.
Since we have some developers actively working on the test suite, it appears that you are more annoyed with the noise during “svn up” rather than any actual “bloat”.
Mark.
[1] http://en.wikipedia.org/wiki/Gender-neutral_pronoun [2] du -sk * maintenance/tests/ | perl -ne 'chomp;($c, $l) = \ m{(\S+)\s+(\S+)}; $w = $c/3652;print sprintf ("%0.3f $l\n", $w);' \ | sort -n
Mark A. Hershberger wrote:
MZMcBride z@mzmcbride.com writes:
Even if we could say that most users downloading from SVN are interested in development, I don't see how that extends to saying that test suites are required for development. You've lost me.
If a developer breaks a test, ze[1] should fix it. As the tests cover more and more of the code, the tests should be considered more integral to development since they provide a nice sanity check on any changes a developer is likely to make.
I think the idea that only people intending to do development work on MediaWiki download from SVN is a bit insane. And as you note, these tests are only going to grow in size over time.
The maintenance directory has maintenance tools in it. I don't think test suites fall within the category of "maintenance." Like large artwork files, these seem to be "development" tools that shouldn't be downloaded with every phase3 checkout.
[...]
That is, the tests directory is only 1/4 of the size of the entire maintenance directory. The includes directory is almost 15 times larger than the tests directory and, yes, languages tops them all.
You seem to be making an argument that other parts of phase3 need examination and possible trimming. I agree.
Since we have some developers actively working on the test suite, it appears that you are more annoyed with the noise during ³svn up² rather than any actual ³bloat².
I wouldn't say it's noise. But checkouts take longer and there are more files to deal with in the directory. When I see them filling up space on my servers (admittedly not a lot of space), I think it's reasonable to ask why everyone is downloading these tests when relatively so few people will ever run them or need them.
I've come to accept that downloading from SVN is just going to include these tests. As I wrote on the bug[1] earlier today, there seems to be consensus to keep the tests directory in phase3, though perhaps move it a directory up.
The larger question now is whether to include the tests in the released tarbells.
MZMcBride
I think the idea that only people intending to do development work on MediaWiki download from SVN is a bit insane. And as you note, these tests are only going to grow in size over time.
This whole discussion is bringing an analogy to a PHP framework that I'm using a lot now, symfony [1]. Their SVN is even larger than MediaWiki's. A large part of that is for languages (which, by the way, are not only languages, but every single culture too), and lots of unit tests. 99.99% of users don't need them, but they package them anyway. I think that the whole discussion should be moot, as 40MB is not that much in comparison to other codebases. Either way, people will need far more than 40MB of space on the server to run a good wiki, and not very many people have a server that would have less in the first place.
-X!
On 06/12/10 09:07, MZMcBride wrote:
The maintenance directory has maintenance tools in it. I don't think test suites fall within the category of "maintenance." Like large artwork files, these seem to be "development" tools that shouldn't be downloaded with every phase3 checkout.
On the second part, I disagree with you since development tools must be part of MediaWiki core for development purposes. I do agree though that the tests themselves should probably live in their own repository such as "phase3/tests". That is where Avar put them originally (or it was "phase3/t" which is "prove" default path).
This way you can easily ignore the "tests" directory but keep the actual test framework in "maintenance/tests/".
I'm the first to add a vote to https://bugzilla.wikimedia.org/show_bug.cgi?id=26259 ! Hope it gets counted. M> SVN is convenient for installations and upgrades. That's certainly M> why I use it. Me too. Please move all the expert testing stuff to a different place where the experts can use an expert command to fetch it, and stop bloating we regular WikiSysops SVN updates. Thanks.
On Tue, Dec 7, 2010 at 8:59 AM, jidanni@jidanni.org wrote:
I'm the first to add a vote to https://bugzilla.wikimedia.org/show_bug.cgi?id=26259 ! Hope it gets counted. M> SVN is convenient for installations and upgrades. That's certainly M> why I use it. Me too. Please move all the expert testing stuff to a different place where the experts can use an expert command to fetch it, and stop bloating we regular WikiSysops SVN updates. Thanks.
The consensus is that they're not moving it out of /trunk/phase3. It probably will move from maintenance/tests/ to just tests/.
-Chad
On Tue, Dec 7, 2010 at 9:02 AM, Chad innocentkiller@gmail.com wrote:
The consensus is that they're not moving it out of /trunk/phase3.
s/they/we/
(not sure why I left myself out of this...)
-Chad
"Chad" innocentkiller@gmail.com wrote in message news:AANLkTim8_yyY0Sfhg=a-ES+ST2bUx9YAkECvsmpOvb0A@mail.gmail.com...
On Tue, Dec 7, 2010 at 8:59 AM, jidanni@jidanni.org wrote:
I'm the first to add a vote to https://bugzilla.wikimedia.org/show_bug.cgi?id=26259 ! Hope it gets counted. M> SVN is convenient for installations and upgrades. That's certainly M> why I use it. Me too. Please move all the expert testing stuff to a different place where the experts can use an expert command to fetch it, and stop bloating we regular WikiSysops SVN updates. Thanks.
The consensus is that they're not moving it out of /trunk/phase3. It probably will move from maintenance/tests/ to just tests/.
-Chad
I never really understood why they went into /maintenance/tests in the first place.
--HM
On 12/12/10 11:39, Happy-melon wrote: <snip>
I never really understood why they went into /maintenance/tests in the first place.
Maxsem moved them with r61945 :
"Moved tests to maintenance - one directory less to care about when configuring access."
http://svn.wikimedia.org/viewvc/mediawiki?view=revision&revision=61945
On 07/12/10 14:59, jidanni@jidanni.org wrote:
M> SVN is convenient for installations and upgrades. That's certainly M> why I use it. Me too. Please move all the expert testing stuff to a different place where the experts can use an expert command to fetch it, and stop bloating we regular WikiSysops SVN updates. Thanks.
svn is already considered "expert stuff" ;-)
On 7 December 2010 14:59, jidanni@jidanni.org wrote:
Me too. Please move all the expert testing stuff to a different place where the experts can use an expert command to fetch it, and stop bloating we regular WikiSysops SVN updates. Thanks.
Well, the hint to use sparse checkouts applies this way, too… You can omit the testing directories from your checkout, and even subsequent SVN updates will skip them. After checkout, just call svn up --set-depth exclude maintenance/tests and you should be set.
-- [[cs:User:Mormegil | Petr Kadlec]]
On 7 December 2010 20:08, Petr Kadlec petr.kadlec@gmail.com wrote:
Well, the hint to use sparse checkouts applies this way, too… You can omit the testing directories from your checkout, and even subsequent SVN updates will skip them. After checkout, just call svn up --set-depth exclude maintenance/tests and you should be set.
svn up --set-depth exclude maintenance/tests svn: 'exclude' is not a valid depth; try 'empty', 'files', 'immediates', or 'infinity'
There is no mention of 'exclude' even in the docs of development version of svn.
-Niklas
On 7 December 2010 19:43, Niklas Laxström niklas.laxstrom@gmail.com wrote:
On 7 December 2010 20:08, Petr Kadlec petr.kadlec@gmail.com wrote:
Well, the hint to use sparse checkouts applies this way, too… You can omit the testing directories from your checkout, and even subsequent SVN updates will skip them. After checkout, just call svn up --set-depth exclude maintenance/tests and you should be set.
svn up --set-depth exclude maintenance/tests svn: 'exclude' is not a valid depth; try 'empty', 'files', 'immediates', or 'infinity'
There is no mention of 'exclude' even in the docs of development version of svn.
The exclude option is new in 1.6, see http://subversion.apache.org/docs/release-notes/1.6.html#sparse-directory-exclusion and http://blogs.open.collab.net/svn/2009/03/sparse-directories-now-with-exclusion.html. In 1.5, I you need to use --set-depth empty, I guess.
-- [[cs:User:Mormegil | Petr Kadlec]]
On 6 December 2010 08:47, Ashar Voultoiz hashar+wmf@free.fr wrote:
- I want to be able to commit a bug fix + associated tests in one revision without having to fetch the whole phase3 tree.
You don’t have to. Subversion supports (since 1.5?) sparse checkouts http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html, allowing you to have only selected parts of a directory checked out in your working copy, which is a feature suitable exactly for scenarios like this one.
-- [[cs:User:Mormegil | Petr Kadlec]]
On 6 December 2010 12:08, Petr Kadlec petr.kadlec@gmail.com wrote:
On 6 December 2010 08:47, Ashar Voultoiz hashar+wmf@free.fr wrote:
- I want to be able to commit a bug fix + associated tests in one revision without having to fetch the whole phase3 tree.
You don’t have to. Subversion supports (since 1.5?) sparse checkouts http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html, allowing you to have only selected parts of a directory checked out in your working copy, which is a feature suitable exactly for scenarios like this one.
Except it is still too inconvenient to use for most cases (yeah I was going to suggest it too): "Subversion 1.5's implementation of shallow checkouts is good but does not support a couple of interesting behaviors. First, you cannot de-telescope a working copy item. Running svn update --set-depth empty in an infinite-depth working copy will not have the effect of discarding everything but the topmost directory—it will simply error out. Second, there is no depth value to indicate that you wish an item to be explicitly excluded. You have to do implicit exclusion of an item by including everything else."
-Niklas
Hi all,
concerning the selenium part of the tests, I suggest to treat functional tests and regression tests differently: * The framework and test runner should remain in maintenance/tests, since it provides a testing infrastructure for MW * We are working on a MediaWiki smoke test which makes sure the wiki is basically up and running. I think, that kind of tests makes perfect sense within phase3, since they might also be run by someone who sets up a wiki and wants to make sure everything in the installation went ok. Also, extension developers could use them to ensure their work didn't break any basic functionality. * Regression tests for bugfixes go to some separate place, since there might be a large number of them. I can see Ashar's point, though. Maybe a solution could be to put them in a separate tests folder and ignore this one when bundling a tarball? A similar system might also make sense for unit tests.
Cheers, Markus (mglaser)
On 6 December 2010 12:08, Petr Kadlec petr.kadlec@gmail.com wrote:
On 6 December 2010 08:47, Ashar Voultoiz hashar+wmf@free.fr wrote:
- I want to be able to commit a bug fix + associated tests in one revision without having to fetch the whole phase3 tree.
You don't have to. Subversion supports (since 1.5?) sparse checkouts http://svnbook.red-bean.com/en/1.5/svn.advanced.sparsedirs.html, allowing you to have only selected parts of a directory checked out in your working copy, which is a feature suitable exactly for scenarios like this one.
Except it is still too inconvenient to use for most cases (yeah I was going to suggest it too): "Subversion 1.5's implementation of shallow checkouts is good but does not support a couple of interesting behaviors. First, you cannot de-telescope a working copy item. Running svn update --set-depth empty in an infinite-depth working copy will not have the effect of discarding everything but the topmost directory-it will simply error out. Second, there is no depth value to indicate that you wish an item to be explicitly excluded. You have to do implicit exclusion of an item by including everything else."
-Niklas
-- Niklas Laxström
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org