Last modified: 2009-10-06 08:41:50 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T21741, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 19741 - Large files being distributed with MediaWiki
Large files being distributed with MediaWiki
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
1.16.x
All All
: Normal enhancement (vote)
: ---
Assigned To: Tim Starling
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-15 10:41 UTC by Dan Jacobson
Modified: 2009-10-06 08:41 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dan Jacobson 2009-07-15 10:41:15 UTC
Gentlemen, can we get some consensus on distributing large files?
$ find -type f|fgrep -v /.svn|xargs du|sort -nr
2112    ./js2/mwEmbed/example_usage/media/sample_fish.ogg
845     ./skins/common/images/mediawiki-largesquare.xcf
661     ./skins/common/images/mediawiki-large.xcf
548     ./js2/mwEmbed/example_usage/media/sample_jellyfish.ogg

E.g., aren't the .xcf's something that Gimp aficionados could download
on their own? And then there's the blockbuster .ogg's.

Can't the basic MediaWiki stay slim and trim, and any extras be separately
downloadable for those that need them, or put into an extension?

Perhaps we can say "are they needed in daily operation?"

"Would it make more sense/be more efficient if they were available separately for those who are interested?"
Comment 1 Dan Jacobson 2009-07-15 17:23:47 UTC
I used to be able to do (rgrep "PATTERN" "*" "~/mediawiki/") in emacs in a jiffy... now it's plowing through big files...
Comment 2 Michael Dale 2009-07-15 17:58:02 UTC
I think its convenient to store the xcfs near the files that are outputted from those xcfs ... perhaps those can be removed in "release" versions? and or a deployment branch? Likewise the local media files are convenient for local testing of mwEmbed components. But I can move thous to a url if the deployment branch / release versions are not satisfactory.
Comment 3 Dan Jacobson 2009-07-15 18:10:00 UTC
Maybe the xcf's are there in the spirit of "when we say full source
code, we mean it". Yes, we get the idea, but OK, but please put them
somewhere else.

Also SVN==release, at least for me. And if you pull things out upon
making tarballs, things will tend to break. They should either all the
way in or all the way _out_.
Comment 4 Brion Vibber 2009-07-27 17:03:44 UTC
Release issue -- Tim can you see if we've got a better place to stick these?

We've been trimming the .xcf logos from release tarballs, but it'd be nice if a straight SVN checkout is clean too.
Comment 5 Michael Dale 2009-07-27 21:53:30 UTC
Removed all the sample video files in favor of remote urls r53838
Comment 6 Dan Jacobson 2009-08-04 22:19:59 UTC
Repening: .XCFs still remain and now are the worst offenders:

$ find -type f|fgrep -v /.svn|xargs du|sort -nr|head -n 2
845     ./skins/common/images/mediawiki-largesquare.xcf
661     ./skins/common/images/mediawiki-large.xcf

$ find * -name \*.xcf
js2/mwEmbed/skins/mvpcf/images/stock_icon_over.xcf
skins/common/images/icons/fileicon-ogg.xcf
skins/common/images/icons/fileicon-djvu.xcf
skins/common/images/mediawiki-small.xcf
skins/common/images/fileicon.xcf
skins/common/images/mediawiki-large.xcf
skins/common/images/gnu-fdl.xcf
skins/common/images/Arr_r.xcf
skins/common/images/mediawiki-largesquare.xcf
Comment 7 Tim Starling 2009-10-06 08:41:50 UTC
Fixed in r57420.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links