Thanks for bringing this up, Brion. I've been hoping we could have this
conversation for a while now.
Before coming to WMF, I worked for a number of years as a broadcast
engineer for a fairly popular video site. So, I've researched this in some
depth. Here's a summary.
First, let's talk about
On Tue, Mar 20, 2012 at 3:38 PM, David Gerard wrote:
> On 20 March 2012 19:06, Ian Baker wrote:
>
> > * WebM (aka VP8) is really not bad, but is technically inferior to h.264
> > Main and High Profiles[1].
>
> This comparison appears specious in the context of this threa
>
>
> *nod* for our purposes even Theora is "good enough" to put pretty pictures
> on the screen; we're not super concerned with the ideal codec, as much as
> making sure that people can actually get access to the media files we have
> -- the binary "works" / "doesn't work" is more important.
Tha
>
>
> If someone wants to write up a memo with pros/cons of targeting that
> smartphone h264 support, that would be helpful in case we want to move
> this to Board-level reviews.
>
>
I'd be into helping out with this. Does anyone want to work on it with me?
-Ian
__
I've made a minor API change ApiUpload, for stashed files. It's not a
commonly used API and the change shouldn't break anything external, but I
figured I should post just in case.
Temporarily stashed files now have their metadata stored in the database
instead of the session. This allows for som
>
>
> >
> > The actual change to the API is pretty simple. First, the 'sessionkey'
> > parameter has been superseded by 'filekey', though 'sessionkey' remains
> for
> > compatibility.
>
>
> Seems to me like this doesn't need any client-visible changes; any
> objection
> to just leaving it labeled
Thanks for bringing this up! I don't have any answers, but there's a
feature I'd like to build on this dataset. I wonder if bringing this stuff
into a more readily available database could be part of that project in some
way.
Basically, I'd like to publish per-editor pageview stats. That is,
Me
On Thu, Aug 11, 2011 at 8:23 PM, MZMcBride wrote:
>
> This is a neat idea. MediaWiki has some page view count support built in,
> but it's been disabled on Wikimedia wikis for pretty much forever. The
> reality is that MediaWiki isn't launched for the vast majority of requests.
> A user making an
Hey, Domas! Firstly, sorry to confuse you with Dario earlier. I am so very
bad with names. :)
Secondly, thank you for putting together the data we have today. I'm not
sure if anyone's mentioned it lately, but it's clearly a really useful
thing. I think that's why we're having this conversatio
>
>
> I think building an efficiently queryable set of all historic data is
> unrealistic without a separate cluster. We're talking 100GB/year, before
> indexing, which is about 400GB if we go back to 2008.
>
[etc]
So, these numbers were based on my incorrect assumption that the data I was
lookin
I took a little time last week and wrapped Neik K's parserPlus library into
an extension. It implements a nice framework for grabbing localized message
strings, with limited but very useful PEG-based wikitext parsing, all on the
client-side. This is code that's been in use in UploadWizard for som
>
>
> On the one hand, this seems like a potentially useful feature. On the
> other, it sounds like a very controversial feature that will present new
> opportunities for spam, not to mention working out a way that help can be
> provided uniformly across the board.
>
> I'd really like to read more
Along these lines, does it make sense to develop extensions against the last
release when possible (that is, avoid new interfaces until they're actually
available)? Extensions are coded a lot faster than core, and are released
more often, but our default behavior seems to be to code against trunk,
>
>
> I've talked to some of the ops folks a bit, and we've already agreed
> that inline display of diffs is something we really need to add to
> Gerrit. I've filed a feature request to this end:
> http://code.google.com/p/gerrit/issues/detail?id=1137
It's worth pointing out that Google Code will
Hi, everyone. I'm looking for some clarification about the process whereby
code gets deployed on the Wikimedia cluster. Not so much the technical
side of things, and in fact, I'd love to keep this conversation
VCS-agnostic. We'll be moving to git soon and things will change, but
these questions
On Wed, Dec 14, 2011 at 10:57 PM, Tim Starling wrote:
> Usually an experienced developer, most often with shell access, needs
> to champion a contributed extension if it's going to be deployed.
> Championing can be a long and complex process.
>
> There is no written policy that says this, and mayb
16 matches
Mail list logo
