Chad [innocentkil...@gmail.com] writes:
in discussions elsewhere)...we *really* need to have a FileStore-esque
class that abstracts file system operations.
Yep. The only real question is whether we tie it to the SwiftMedia project, or
whether we split it out into a separate refactoring
...@gmail.com]
Sent: Tuesday, September 27, 2011 6:23 AM
To: Wikimedia developers
Subject: Re: [Wikitech-l] originals via API, but thumbs local?
On Tue, Sep 27, 2011 at 4:28 AM, Russell N. Nelson - rnnelson
rnnel...@clarkson.edu wrote:
I'm hoping that someone can answer this question off the cuff. Please
I'm hoping that someone can answer this question off the cuff. Please don't do
any research; that's my job.
When I fetch an image via the API from a remote wiki using ForeignAPIRepo, the
thumbnails end up with a local URL How do get it to use the remote thumbnail
URL? E.g. as on this page:
It is meaningless to talk about cryptography without a threat model, just as
Robert says. Is anybody actually attacking us? Or are we worried about
accidental collisions?
Sent from my Verizon Wireless Phone
-Original message-
From: Robert Rohde raro...@gmail.com
To: Wikimedia
What is the threat?
Sent from my Verizon Wireless Phone
-Original message-
From: Ilmari Karonen nos...@vyznev.net
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Sent: Sun, Sep 18, 2011 20:20:34 GMT+00:00
Subject: Re: [Wikitech-l] Adding MD5 / SHA1 column to revision table
Geez, I didn't mean to squash the discussion! TRAC isn't *that* weird a
language, is it?
From: wikitech-l-boun...@lists.wikimedia.org
[wikitech-l-boun...@lists.wikimedia.org] on behalf of Russell N. Nelson -
rnnelson [rnnel...@clarkson.edu]
Sent
in it.
On Sun, Sep 11, 2011 at 12:05 PM, Russell N. Nelson - rnnelson
rnnel...@clarkson.edu wrote:
Geez, I didn't mean to squash the discussion! TRAC isn't *that* weird a
language, is it?
From: wikitech-l-boun...@lists.wikimedia.org [
wikitech-l-boun
How about http://en.wikipedia.org/wiki/TRAC_%28programming_language%29 ?
It has the benefit that simple things are simple, but you can create
complicated things because it's a full programming language.
___
Wikitech-l mailing list
On the other hand, if you never clean up cruft, you advance the date at which a
rewrite from scratch becomes necessary. Code which hasn't had the entropy
removed becomes brittle and hard to understand.
Sent from my Verizon Wireless Phone
-Original message-
From: Rob Lanphier
Treat the concurrent session as a single revision and the combined work product
of all participating editors.
Sent from my Verizon Wireless Phone
-Original message-
From: Thomas Dalton thomas.dal...@gmail.com
To: Wikimedia developers wikitech-l@lists.wikimedia.org
Sent: Sun, Sep 4,
volunteer to test it
and report back.
From: wikitech-l-boun...@lists.wikimedia.org
[wikitech-l-boun...@lists.wikimedia.org] on behalf of Russell N. Nelson -
rnnelson [rnnel...@clarkson.edu]
Sent: Thursday, August 25, 2011 4:42 PM
To: Wikimedia developers
Subject
https://bugzilla.wikimedia.org/30192 -- Thumbnails of archived images
don't get deleted
I've got my head down in this code. I'll have a go at it.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
Subject: Re: [Wikitech-l] Ramping up to 1.18 deployment
On Thu, Aug 25, 2011 at 4:42 PM, Russell N. Nelson - rnnelson
rnnel...@clarkson.edu wrote:
https://bugzilla.wikimedia.org/30192 -- Thumbnails of archived images
don't get deleted
I've got my head down in this code. I'll have a go
The problem is that 1) the files are bulky, 2) there are many of them, 3) they
are in constant flux, and 4) it's likely that your connection would close for
whatever reason part-way through the download.. Even taking a snapshot of the
filenames is dicey. By the time you finish, it's likely that
of Peter Gervai
[grin...@gmail.com]
Sent: Monday, August 15, 2011 5:40 PM
To: Wikimedia developers
Subject: Re: [Wikitech-l] forking media files
On Mon, Aug 15, 2011 at 18:40, Russell N. Nelson - rnnelson
rnnel...@clarkson.edu wrote:
The problem is that 1) the files are bulky,
That's expected
...@lists.wikimedia.org
[wikitech-l-boun...@lists.wikimedia.org] on behalf of Brion Vibber
[br...@pobox.com]
Sent: Monday, August 15, 2011 6:31 PM
To: Wikimedia developers
Subject: Re: [Wikitech-l] forking media files
On Mon, Aug 15, 2011 at 3:14 PM, Russell N. Nelson - rnnelson
rnnel...@clarkson.edu
To: Wikimedia developers
Subject: Re: [Wikitech-l] forking media files
On Mon, Aug 15, 2011 at 4:16 PM, Russell N. Nelson - rnnelson
rnnel...@clarkson.edu wrote:
rsync doesn't have the MW database to consult for changes.
That's an implementation detail, isn't it? GNU tar doesn't either
I see several paths forward on this:
1) Make an existing protocol and client work. Whether ftp or rsync or http or
scp, they think they're copying a tree of filles.
a) Give people access to something that looks like a tree of folders, and
just let them recurse as needed using wget -m. Doesn't
Hi. I'm working on Extension:SwiftMedia, and I've got it into pretty decent
shape. No known bugs (last bug was a coding bug; bug prior was a design bug).
Since the plan is to switch Wikipedia over to this media storage system, we're
trying to be as conservative and not-break-it as possible. If
Fish bowl is easy. You have two concentric circles of chairs. The inner circle
are the people speaking. When someone in the inner circle has spoken their
piece, they get up, and somebody from the outer circle can move in. Less
pressure on the speakers to say something. If you have nothing
at Wikimania
On 01.08.2011 15:50, Russell N. Nelson - rnnelson wrote:
Fish bowl is easy. You have two concentric circles of chairs. The inner
circle are the people speaking. When someone in the inner circle has spoken
their piece, they get up, and somebody from the outer circle can move in.
Less
Go for it. Def not in our interest to spend money, but if it's just a our
interests are aligned then it's only true.
From: wikitech-l-boun...@lists.wikimedia.org
[wikitech-l-boun...@lists.wikimedia.org] on behalf of Ryan Kaldari
[rkald...@wikimedia.org]
SwiftMedia might be a key piece in the puzzle. It should scale well beyond a
petabyte. Of course, first we have to get it working and serving up the first
12GB (thumbs + originals). Getting very close ...
-russ
From: wikitech-l-boun...@lists.wikimedia.org
Another possibility is for us to 1) announce that IE6 is no longer a supported
browser, and 2) just stop worrying about IE6. Not take support out, but not
worry about IE6. Don't test using it, don't code for it, don't pay any
attention to new IE6 vulns. Just let the IE6 support die through
Remember Rule #1: You can't solve social problems using technical means. The
social problem is that people keep using IE6. The technical means are to
protect them by pandering to IE6 security lapses. The social solution is to
tell people FFS, STOP USING IE^111.
For all the reasons Brion gave
Varnish for load.php) between us and the IE users, and I'm not sure we
can tell them to only not cache requests for IE6.
This might work:
acl ffsnoie6 browser ie6
no_cache deny ffsnoie6
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
I've done release engineering before. It is my considered opinion that one
person needs to be on point for each release. It's possible that that person
could rotate in and out, but one person needs to be running through the
checklist of things that need to be done.
Well, AFAIK our bottleneck is reviewing.
I don't think that's the only bottleneck. An unwillingness to release code is a
sign of a lack of trust. Reviewed code is a source of trust. But there are
other sources of trust:
o code reviews
o test cases (a bug isn't fixed until there's a test
Robla writes:
1. We say that a commit has some fixed window (e.g. 72 hours) to get
reviewed, or else it is subject to automatic reversion. This will
motivate committers to make sure they have a reviewer lined up, and
make it clear that, if their code gets reverted, it's nothing
personal...it's
It looks to me like this code is a trope:
if ( $repo-isVirtualUrl( $path ) ) {
$path = $repo-resolveVirtualUrl( $path );
}
Or in this form:
if ( self::isVirtualUrl( $file ) ) {
// This is a virtual url, resolve it
Isn't that essentially a binary rating system, where the only two ratings are
Necessary and Optional, depending on their presence in /modules versus
/extensions? It's a good idea -- make no mistake -- but let's be deliberate
about having only two ratings.
With encouragement from folks on#mediawiki, I'm being bold and proposing that
we deprecate getFullPath(). All it does is call getPath(), and there are only
three in-tree consumers of it, as opposed to a bazillion consumers of
getPath():
Maybe there's a better tool to tell you what function is defined in what class
in PHP, but I couldn't find one in the time it would take me to write it, so I
wrote it. It's not even a screenful. Give it the class definitions, in class
hierarchy order, on the command line. It will pull out the
...@lists.wikimedia.org] on behalf of Brion Vibber
[br...@pobox.com]
Sent: Monday, May 02, 2011 7:24 PM
To: Wikimedia developers
Subject: Re: [Wikitech-l] auditcode.py - discern class structure
On Mon, May 2, 2011 at 4:21 PM, Russell N. Nelson - rnnelson
rnnel...@clarkson.edu wrote:
Maybe there's
Bounces? That is, some return codes from a program delivery can be interpreted
as a failed delivery. Or perhaps the program is segfaulting or running out of
memory? Or replies sent to the envelope sender, which can be interpreted as
bounces, but which lack the empty sender of a real bounce.
35 matches
Mail list logo
