On Wed, Feb 16, 2011 at 2:12 AM, Ashar Voultoiz wrote:
> On 14/02/11 15:11, Roan Kattouw wrote:
>> By the time we deploy 1.17, trunk will
>> already be more than two months ahead. Of course this is because we
>> needed time to stabilize 1.17, which in turn was caused by the amount
>> of new code i
On Tue, Feb 15, 2011 at 11:25 PM, Ashar Voultoiz wrote:
> On 16/02/11 05:50, Jay Ashworth wrote:
>>> Ok, so offering HTTPS for everything isn't essential. What harm does
>>> it do, though?
>>
>> it imposes on your server cluster some requirements -- and some load --
>> with which it would otherwis
On 16/02/11 05:50, Jay Ashworth wrote:
>> Ok, so offering HTTPS for everything isn't essential. What harm does
>> it do, though?
>
> it imposes on your server cluster some requirements -- and some load --
> with which it would otherwise not have to deal.
I think most load balancer appliances aroun
On 14/02/11 15:11, Roan Kattouw wrote:
> By the time we deploy 1.17, trunk will
> already be more than two months ahead. Of course this is because we
> needed time to stabilize 1.17, which in turn was caused by the amount
> of new code in it.
What about stopping adding new code in trunk until the
* Platonides [Wed, 16 Feb 2011 00:40:38 +0100]:
> MZMcBride wrote:
> > To this end, I filed a JIRA ticket with the Toolserver ops about
> getting the
> > Wikimedia Bugzilla database replicated with public views:
> > https://jira.toolserver.org/browse/TS-901
>
> The bugzilla db is on a different ma
- Original Message -
> From: "Thomas Dalton"
> Ok, so offering HTTPS for everything isn't essential. What harm does
> it do, though?
it imposes on your server cluster some requirements -- and some load --
with which it would otherwise not have to deal.
Cheers,
-- jra
__
- Original Message -
> From: jida...@jidanni.org
> Is that how Facebook™ or Google™ operate, sending every single
> component via HTTPS?
>
> No. Only the vital personal settings, password stuff is done that way.
Wrong.
Both Google and Facebook will be perfectly happy to let you conduct
y
( repost from http://techblog.wikimedia.org )
Continuing with the work started last week[1], we plan to deploy 1.17
to more wikis in a couple hours. We had hoped we would be able to
figure out the performance issues in the past week, but unfortunately,
the only practical way we have to see the lo
Walter McGinnis wrote:
>>> All this boils down to, yes full HTTPS is best practice, but if you make use
>>> of external APIs or services, it may be hard to achieve.
>>
>> Using an external API or service by including stuff from third-party
>> sites would send users' IP addresses to those sites, wh
> On Tue, Feb 15, 2011 at 12:58 PM, Q wrote:
> > On 2/15/2011 11:34 AM, Anthony Ventresque (Dr) wrote:
> >> Wikipedia... is that a relevant answer to your remark?
> >
> > There's about 284 of those, you'll have to be a bit more specific.
>
> Anyone who says "Wikipedia", in English, in a context t
Never mind. I'll postprocess it myself. How silly of me. What could be simpler?
svn diff -r BASE:HEAD RELEASE-NOTES|
perl -nlwe 'next if 1../^\@\@/;print if /^[-+]/'|
perl -we 'local $/; while(<>){s/\n[+\- ] / /g;print}'|
perl -nwle 's/\s+$//;tr/ //s;next unless length;/(.)(.*)/;$h{$2}+=(eval $1 .
On 11-02-15 07:56 AM, Platonides wrote:
> Daniel Friesen wrote:
>> However a key thing to note is that git submodules aren't anything
>> really special. Sure, they're integrated into git, but the only real
>> special feature about them is that you can target a specific commit
>> id... and heck, we
On Feb 16, 2011, at 12:43 PM, Aryeh Gregor wrote:
> On Tue, Feb 15, 2011 at 4:36 PM, Walter McGinnis wrote:
>> Now, in practice implementing this has challenges. I'm the lead developer on
>> Kete, an open source Ruby on Rails app (http://kete.net.nz), and recently
>> wanted to make the switch t
On 15 February 2011 15:43, Aryeh Gregor wrote:
> Using an external API or service by including stuff from third-party
> sites would send users' IP addresses to those sites, which would
> violate Wikimedia's privacy policy, so this isn't an issue for us.
There are people loading javascript from to
On Tue, Feb 15, 2011 at 4:36 PM, Walter McGinnis wrote:
> Now, in practice implementing this has challenges. I'm the lead developer on
> Kete, an open source Ruby on Rails app (http://kete.net.nz), and recently
> wanted to make the switch to fully HTTPS for a site and the Kete app when
> used w
MZMcBride wrote:
> To this end, I filed a JIRA ticket with the Toolserver ops about getting the
> Wikimedia Bugzilla database replicated with public views:
> https://jira.toolserver.org/browse/TS-901
The bugzilla db is on a different machine, it may not be worth it.
Leo wrote:
> One thing that b
On Tue, Feb 15, 2011 at 12:58 PM, Q wrote:
> On 2/15/2011 11:34 AM, Anthony Ventresque (Dr) wrote:
>> Wikipedia... is that a relevant answer to your remark?
>
> There's about 284 of those, you'll have to be a bit more specific.
Anyone who says "Wikipedia", in English, in a context that makes it
c
I talked to Hampton yesterday about the current Mobile site and, since
it was discussed here recently, I thought I'd try to update you all on
what he told me.
First, Hampton mentioned that while he, personally, isn't doing any work
on the Mobile rewrite (I think Tomasz Finc is trying to find some
On Tue, Feb 15, 2011 at 6:01 PM, wrote:
> I don't want a bunch of whitespace diffs clogging up my view of the real
> changes. Nor do I want a more detailed view. Nor do I want to need to
> write a script to post process the diffs.
>
Nor should we have to change what's worked just fine for years
> "K" == Krinkle writes:
K> I'd say, don't read diffs, but read the actual release notes file.
Too much info.
K> Who cares about wether or not a bit of whitespace changed ?
My argument exactly.
Every couple weeks I do
$ svn diff -r BASE:HEAD RELEASE-NOTES
and if all looks safe, I then do
$ s
jidanni wrote:
> Please ensure that no diff will contain boring formatting changes.
>
> That means they must be properly formatted when they enter the file,
> or never
Release-notes are in chronological order.
I'd say, don't read diffs, but read the actual release notes file.
Who cares about we
On Wed, Feb 16, 2011 at 8:37 AM, wrote:
>> "C" == Chad writes:
> C> Then it should be fixed. Better in a batch commit than
> C> in a dozen separate ones. I don't see what the problem
> C> is here.
>
> Please ensure that no diff will contain boring formatting changes.
>
> That means they mus
> "C" == Chad writes:
C> Then it should be fixed. Better in a batch commit than
C> in a dozen separate ones. I don't see what the problem
C> is here.
Please ensure that no diff will contain boring formatting changes.
That means they must be properly formatted when they enter the file,
or n
On Tue, Feb 15, 2011 at 2:06 PM, Ryan Lane wrote:
>> All this boils down to, yes full HTTPS is best practice, but if you make use
>> of external APIs or services, it may be hard to achieve.
>>
>
> We don't for anything, I believe.
>
> - Ryan Lane
There was some discussion on making secure.wikime
> All this boils down to, yes full HTTPS is best practice, but if you make use
> of external APIs or services, it may be hard to achieve.
>
We don't for anything, I believe.
- Ryan Lane
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https:
2011/2/15 Thomas Dalton :
> Ok, so offering HTTPS for everything isn't essential. What harm does
> it do, though?
>
Exactly. We're not gonna force users to use HTTPS for everything, but
we should at least offer the possibility to those who want it.
Roan Kattouw (Catrope)
_
> On Tue, Feb 15, 2011 at 1:09 PM, wrote:
>> Is that how Facebook™ or Google™ operate, sending every single component
>> via HTTPS?
>>
>> No. Only the vital personal settings, password stuff is done that way.
Actually, there's now a setting in Facebook to use https on every
single page request.
On 15 February 2011 21:09, wrote:
> Is that how Facebook™ or Google™ operate, sending every single component
> via HTTPS?
>
> No. Only the vital personal settings, password stuff is done that way.
>
> As for not letting people know what pages you are browsing, well, I
> don't now. Does Google™ of
On Tue, Feb 15, 2011 at 1:09 PM, wrote:
> Is that how Facebook™ or Google™ operate, sending every single component
> via HTTPS?
>
> No. Only the vital personal settings, password stuff is done that way.
>
> As for not letting people know what pages you are browsing, well, I
> don't now. Does Goog
On Feb 16, 2011, at 10:21 AM, Brandon Harris wrote:
>
> Lots of people don't like to have their sessions stolen via Firesheep.
> That's one reason to do "all https all the time".
I think y'all should chill and take the tone down from an argument to more of
discussion where points of vie
On Tue, Feb 15, 2011 at 4:21 PM, wrote:
>> "C" == Chad writes:
> C> On Sun, Feb 13, 2011 at 10:42 PM, Ashar Voultoiz
> wrote:
>>> We do want to maintains this file at 80 characters line width, we could
>>> even enforce this in a pre-commit hook.
>
> C> Or people could just properly wrap t
On 15 February 2011 22:09, wrote:
> Is that how Facebook™ or Google™ operate, sending every single component
> via HTTPS?
I can't really understand your email. As for having the ability to
read Wikipedia trough a HTTPS conexion. I suppose is useful, wen you
don't want to use cleartext to broad
Lots of people don't like to have their sessions stolen via Firesheep.
That's one reason to do "all https all the time".
On 2/15/11 1:09 PM, jida...@jidanni.org wrote:
> Is that how Facebook™ or Google™ operate, sending every single component
> via HTTPS?
>
> No. Only the vita
> "C" == Chad writes:
C> On Sun, Feb 13, 2011 at 10:42 PM, Ashar Voultoiz wrote:
>> We do want to maintains this file at 80 characters line width, we could
>> even enforce this in a pre-commit hook.
C> Or people could just properly wrap their lines. There's no
C> need for a hook.
And what
> "BV" == Brion Vibber writes:
BV> Bugzilla actually ships with a default robots.txt that denies everything, we
BV> just never removed it. :)
Time to do the same for these lists.
(Psst, news.tcx.org.uk is now publishing them too, one more nail in the
coffin of security via obscurity.)
___
When you finally retire
https://secure.wikimedia.org/wikipedia/commons/... etc.
etc. Have them HTTP 301 permanently redirect to
https://commons.wikimedia.org/... etc.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/
Is that how Facebook™ or Google™ operate, sending every single component
via HTTPS?
No. Only the vital personal settings, password stuff is done that way.
As for not letting people know what pages you are browsing, well, I
don't now. Does Google™ offer a way to not let wiretapping people know
wha
+1 to both, looks to much like another tab and it does something
completely different. Different things should look differently. Might be
even more confusing if the drop down menu arrow would be on the left of
it (then that's usually visible when you log in) - would suggest a
search history but
> With the impending Bugzilla 4 release, I would like to take some
> time in setting up the test instance to perhaps play with some of
> these options to see if we can tweak it into being more useful to
> everyone.
BZ4 is coming? Cool. You can't *imagine* how happy I'd be to help with
that proje
On 2/15/2011 11:34 AM, Anthony Ventresque (Dr) wrote:
>
>> On Tue, Feb 15, 2011 at 9:29 AM, Anthony Ventresque (Dr)
>> wrote:
>>> I was indeed suspecting something like that, but the difference in number
>>> of pages is large while we are talking about a relatively short delay
>>> (minutes?).
>
Depends on the language, enwiki can take weeks to dump, while rue wiki may
only take 30 seconds.
On Tue, Feb 15, 2011 at 12:34 PM, Anthony Ventresque (Dr) <
aventres...@ntu.edu.sg> wrote:
>
> > On Tue, Feb 15, 2011 at 9:29 AM, Anthony Ventresque (Dr)
> > wrote:
> > > I was indeed suspecting some
> On Tue, Feb 15, 2011 at 9:29 AM, Anthony Ventresque (Dr)
> wrote:
> > I was indeed suspecting something like that, but the difference in number
> > of pages is large while we are talking about a relatively short delay
> > (minutes?).
>
> Depending on what site you're talking about.
Wikipedia
Roan Kattouw wrote:
> 2011/2/14 Mark A. Hershberger :
>> If we have a 1.18 branch that is, as Brion has noted (and supported), a
>> day or two behind trunk at most, is there a reason that the we couldn't
>> branch wmfN from the rolling 1.18 branch? Or even just tag it when we
>> wanted to mark a W
On Tue, Feb 15, 2011 at 9:29 AM, Anthony Ventresque (Dr)
wrote:
> I was indeed suspecting something like that, but the difference in number of
> pages is large while we are talking about a relatively short delay (minutes?).
Depending on what site you're talking about.
__
Daniel Friesen wrote:
> However a key thing to note is that git submodules aren't anything
> really special. Sure, they're integrated into git, but the only real
> special feature about them is that you can target a specific commit
> id... and heck, we don't even want that feature, that's the wh
Aryeh Gregor wrote:
> I've used git a lot (I use it for everything I want to version) and
> Mercurial a fair bit (the W3C seems to like it), and I *strongly*
> prefer git. Major problems I have with Mercurial:
>
> 1) It doesn't support lots of useful functionality that's built into
> git unless y
> Anthony Ventresque (Dr) wrote:
> > Hi,
> >
> >
> > I've found something strange in some files. The maximum ids for a page are:
> > latest
> >
> > pages-articles.xml: 29189922
> > page.sql: 28707562
> > categorylinks.sql: 28705949
> > (15,684 categories and 135,521 articles
Anthony Ventresque (Dr) wrote:
> Hi,
>
>
> I've found something strange in some files. The maximum ids for a page are:
> latest
>
> pages-articles.xml: 29189922
> page.sql: 28707562
> categorylinks.sql: 28705949
> (15,684 categories and 135,521 articles are missing)
>
> 2
48 matches
Mail list logo
