Please disable 2-factor authentication on this account - 2016-08-15 - thanks
- User Since
- Oct 7 2014, 2:49 PM (141 w, 2 d)
- IRC Nick
- LDAP User
- MediaWiki User
Resolved by https://gerrit.wikimedia.org/r/336454 as expected
@jcrespo since this change is only really necessary on the beta cluster right now, do we need to file a ticket for that specifically, or is it a separate process that we should do ourselves?
Tue, Jun 20
Yeah, I'm running a script right now to generate a bunch of ~400kb files, but I don't know how much more I can do.
As a preliminary result, I just uploaded a few (read: 10-20) files at a time, both smaller files and larger ones, and I didn't see any significant spike on cluster load during the timeframe of my uploads and first thumbnails. Also, all of the thumbnails generated on the first file page load, regardless of file size, up to about 22MB. I am fairly satisfied that we can handle any increased load due to this new filetype, but if we need additional testing via mass uploads through the API, then we can do so! I just need to find a bigger source of test files, since Thingiverse is getting incredibly tedious to use. (I have some thoughts on this)
Some thoughts from our prioritization:
Tue, Jun 13
Fri, Jun 9
Yeah, I think it's still worth asking whether we really care about this limitation, but if we do, then I'll pursue looking at another control scheme.
Wed, Jun 7
@Gilles nope - when I change those variables to, e.g., Infinity and -Infinity, the only change is that rotating past the poles will make the camera freak out. I also tried adding in a "restrictPolarAngle" configuration, and not checking the angle in that case, but it didn't help.
Tue, Jun 6
So, here are the results of my technical investigation:
Mon, Jun 5
We don't think there have been any problems of this nature for some time, but feel free to reopen if it's still reproducible.
I don't think this is the Multimedia team's purview, removing tag.
Fri, Jun 2
Wed, May 31
Tue, May 30
Thu, May 25
May 23 2017
May 20 2017
May 15 2017
May 8 2017
Given that we removed the category in https://gerrit.wikimedia.org/r/315121, and we now have an open patch, I'm going to reopen this and move it to "Needs review" - to be shortly followed by a close assuming I like the patch.
May 4 2017
It's currently stalled awaiting some form of Wikibase on Commons, we decided it would be better to use that for storage rather than re-write the extension after it's released.
May 3 2017
The actual error message (based on my upload of DavidStatue.stl) is "Internal error: Server failed to store temporary file."
May 2 2017
Taking this now, as it is a requirement for mobile support.
Apr 27 2017
Could use some input as to the balance between the tiny number of people who use this field for a specific purpose that would be useful to readers on other wikis, compared to the tiny number of people who are confused by the field as it is...not sure where we stand on this. Lowering priority due to small impact on both sides.
AFAICT, whatever I was smoking then has gone out of style, and we have mw.Title.newFromImg() which should obviate this issue? Anyway, I don't think we need this.
This should be as simple as removing the class file and replacing wherever the constructor is called with a simple object with the correct properties.
I'm leaving this stalled until structured data is available to clear up the authorship questions present, even in the file you listed as an example. The current structure of the license template and attribution value above are not conducive to us solving this in a good way.
We won't be working on file annotations until we can store them in structured data, so this work is going to wait for a bit. You could work on this based on the current implementation of FileAnnotations, but I wouldn't recommend it, as the implementation will change.
I agree that we don't want to potentially hurt the credit on most files for a tiny use case - and I agree that we should try to fix this once structured data makes it easier for us to credit creators. Leaving stalled, but we definitely want to fix this as soon as is practicable.
Based on the long gap between responses on this bug, I'm going to guess that it's no longer an issue - especially since seemingly none of the examples still cause problems (at least for me).
Apr 25 2017
Should review and improve patch fairly soon.
This can probably be worked on pretty soon.
This is worthwhile, but it's something that will require a lot of looking into the necessity of various dependencies, and bits of code. Hopefully we can schedule this for sometime soon, but unclear exactly when.
This is not a media viewer ticket, reassigning to a more useful project...still something we should look at, though.
This should probably happen after we implement licenses in structured data.
Apr 20 2017
I also cannot reproduce. Given that there is not sufficient information to reproduce or investigate further, I will close this bug - if someone comes back and reopens it, please include more information about your browser and other configuration details so we can actually look into this.
I think this doesn't rise to the level of "normal", as it's a totally optional feature request that would only affect a pretty small subset of files and users...something to think about in the future, but not something we need to rush towards.
I fear the initial triage and investigation may have missed the point of this bug - @Steakyfask1 are you saying that, after exiting the Media Viewer, the scrollbar for the article is disabled? If so, can you please tell us what browser you're using? I could not reproduce this on English Wikipedia with Google Chrome on Linux.
Coming back to MMV bugs after some significant amount of time, I have to agree with @Tgr that, while this may make it harder to test the extension alongside other extensions, it is absolutely true that the tests' assumptions are mistaken. As this is only within the MediaWiki-extensions-MultimediaViewer project, I'm going to lower the priority on this once again and move it to a holding pen on our workboard. If the maintainers of the Cite extension want to take over this task and alter how their tests work, I would be happy to see an increase in priority.
Apr 19 2017
@Ineuw do you want a totally new interface that detects redlinked categories after upload, and offers an option to create a page for them? It's not totally clear the scope of this request, but if you can clarify, I'd be happy to talk with someone about what it would entail.
Apr 18 2017
Updated patch, @Jdlrobson if you want to take another look that would be nice
@Prtksxna would it be sufficient to add role=button et al. to make these accessible in the usual way? It's not clear what specific issue you're looking to solve.
Apr 13 2017
Yeah, that project is long gone.
Mar 28 2017
Mar 26 2017
Mar 10 2017
Mar 7 2017
T159884 maybe a use case for this at some point (mentioning for bookkeeping)
I sent an e-mail to the ops list to ask for some help coming to a resolution on that. I'll post here with a description, along with other tasks if necessary.
Mar 6 2017
Blocked on T157077, will go forward once that's closed.