Raising the awareness of this to more people on mobile-l
---------- Forwarded message ---------- From: Yuri Astrakhan yastrakhan@wikimedia.org Date: Tue, Mar 18, 2014 at 4:38 PM Subject: [zero] reducing image quality
Spoke with Max, and wrote an RFC of what we intend to do. The last portion might need a bit more thinking of who exactly will get the original image quality.
Today Faidon replied on IRC:
...I'm pretty much against moving forward with this unless the simplify
RFChttps://www.mediawiki.org/wiki/Requests_for_comment/Simplify_thumbnail_cachegets implemented...
That RFC was created in 2013-10-07 (5+ months ago), and has not been finalized nor have I found any resources allocated to this project, so it might be a while. Now the question seems to be - would this impact our infrastructure in a significant way without simplify RFC? My calculationshttps://www.mediawiki.org/wiki/Talk:Requests_for_comment/Reducing_image_quality_for_mobile#Impact_on_infrastructure based on Faidon's data suggest that maximum disk usage growth would be 250-500GB extra data size (2.5% growth of the current 20TB), which also equate to 15% increase in the number of files. Hence: 1) are these numbers logical? 2) assuming (1), does 2.5% size growth and 15% number of files growth seem too taxing on our infrastructure to require waiting for simplify RFC technology?
... this is one of the things that as we discussed, we need to plan
ahead in quarterlies etc.; you can't just drop that on us and start experimenting, sorry
This project is following the regular steps - I published it on RFC and posted a proposed code patch. There is no experimentation, only discussion. Even implementing core feature does not increase storage requirement until we have a go ahead from Ops and Mobile and update javascript to use new functionality. Please elaborate what should be the appropriate steps that I might have missed.
On Wed, Mar 26, 2014 at 12:26:04AM -0400, Yuri Astrakhan wrote:
Today Faidon replied on IRC:
(for the benefits of others: I've replied on the RFC itself extensively before that, this was a reply to prodding on an IRC public channel)
That RFC was created in 2013-10-07 (5+ months ago), and has not been finalized nor have I found any resources allocated to this project, so it might be a while.
Yes, but this is orthogonal to whether it's needed or not, isn't it? In fact, dedicating a chunk of time to implement /your/ RFC now is actually going to delay the simplification RFC even further, considering it requires the same expertise and hence more or less the same people that will have to deal with both :)
[ I won't get into the details of the requirement itself for that here, we have the RFC's Talk page & review meetings for that ]
... this is one of the things that as we discussed, we need to plan
ahead in quarterlies etc.; you can't just drop that on us and start experimenting, sorry
This project is following the regular steps - I published it on RFC and posted a proposed code patch. There is no experimentation, only discussion.
The question to which the quote above was a response to was "19:15 <yurikR> paravoid, mark, any further objections to this, or can we start experimenting?". This is where my "experimentation" comment comes from.
The RFC was first written one week ago and got comments from me two hours after it got posted and several times since. My point was/is that I don't think it's reasonable to expect to drop an RFC with a pretty significant impact on our infrastructure and a week later pinging us on IRC asking for "further objections" to start experimenting. We simply haven't planned for this large chunk of time that you're requesting of us all of a sudden, including the time for the RFC review itself. This is not how the RFC process works, anyway: there's RFC review meetings, it needs to gather comments from others, including the architects, get accepted and *then* get implemented.
Thanks, Faidon
Tomasz Finc, 26/03/2014 04:17:
Raising the awareness of this to more people on mobile-l
Thanks. I think this RfC is nowhere near being implemented, or actually even considered. https://www.mediawiki.org/wiki/Talk:Requests_for_comment/Reducing_image_quality_for_mobile#Fundamentals FWIW, the third option I mention can be implemented with a one line config change without any infrastructure impact, AFAICS.
Nemo