2011/2/13 Bryan Tong Minh bryan.tongm...@gmail.com:
This has gotten better lately, WMF created a bugmeister position and
the bugmeister tries to respond to most if not all bugs after being
reported. We should definitely keep up with this and try to at least
confirm every problem that is being
2011/2/12 青子守歌 (aokomoriuta) maill...@enmps.net:
Thank you for your advice.
You mean we should be careful about upgrading jQuery's version if the script
uses jQuery,
i.e. the problem you refer to is not caused if we dont' use jQuery, right?
It's not so much about using jQuery as it is to
2011/2/13 MZMcBride z...@mzmcbride.com:
For example, Meta-Wiki was returning completely blank pages due to the use
of document.write() on pages that contained a particular CSS class. If
document.write() is completely disallowed, it should be noted somewhere
prominently along with other
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In article 18849937.7157.1297583642909.javamail.r...@benjamin.baylink.com,
Jay Ashworth j...@baylink.com wrote:
Yeah, secure.wikimedia.org's URL scheme isn't really friendly
to outsiders. Historically, this is because SSL certificates are
Are there _no_ performance issues we should be concerned about here?
I know local ISP's did (used to?) throttle all encrypted traffic.
Would this fall into that category?
Maury
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
there are actually providers like www.startssl.com who issue free certificates
(only validated by email address though). StartSSLs root certificate is
included in nearly all recent browsers.
Leo
On Sunday, February 13, 2011 at 4:14 PM, River Tarnell wrote:
-BEGIN PGP SIGNED MESSAGE-
afaik, the serverside encryption hasn't got any mentionable performance penalty.
Clients might be a bit slower due to additional roundtrips caused by the
handshakes.
On Sunday, February 13, 2011 at 4:23 PM, Maury Markowitz wrote:
Are there _no_ performance issues we should be concerned about
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In article cfb39d2bb60f411485d2be6d9db07...@gmail.com,
Leo diebu...@gmail.com wrote:
there are actually providers like www.startssl.com who issue free
certificates (only validated by email address though).
StartSSLs root certificate is included
Ah, right. That obviously be too much hassle. Their website is not that clear,
but I think it's 100$ (per year?) for wildcard certificates. (StartSSL™
identity and organization validation are available for only US $ 49.90 each,
where organization validation implies prior identity validation.
MZMcBride wrote:
Guillaume Paumier wrote:
The installation of ResourceLoader may cause compatibility issues
with
existing JavaScript code.
It'd be nice to have a list of things that will definitely be
problematic
(must be fixed), things that might be problematic (should be fixed),
Hi all,
Starting with the wikis that have already been switched I'll make
making a sweep
accross all wikis checking for broken stuff.
Anything directly related and/or broken with 1.17 I will attempt to
fix right away.
Things I see more than one wiki will be noted on the migration guide [1]
- Original Message -
From: River Tarnell r.tarn...@ieee.org
In article
18849937.7157.1297583642909.javamail.r...@benjamin.baylink.com,
Jay Ashworth j...@baylink.com wrote:
Yeah, secure.wikimedia.org's URL scheme isn't really friendly
to outsiders. Historically, this is because
On Sun, Feb 13, 2011 at 9:23 AM, Maury Markowitz
maury.markow...@gmail.com wrote:
Are there _no_ performance issues we should be concerned about here?
I know local ISP's did (used to?) throttle all encrypted traffic.
Would this fall into that category?
Well, there's nothing we can really do
On Sun, Feb 13, 2011 at 9:28 AM, Leo diebu...@gmail.com wrote:
afaik, the serverside encryption hasn't got any mentionable performance
penalty.
Clients might be a bit slower due to additional roundtrips caused by the
handshakes.
On Sunday, February 13, 2011 at 4:23 PM, Maury Markowitz
On Sun, Feb 13, 2011 at 1:51 AM, Jay Ashworth j...@baylink.com wrote:
He's complaining, in effect, that there are more than one URL for identical
content, which is in fact generally a bad idea, but in this case, of course,
he's wrong: different *access protocols* are being used, so it's not
- Original Message -
From: Ryan Lane rlan...@gmail.com
On Sun, Feb 13, 2011 at 1:51 AM, Jay Ashworth j...@baylink.com wrote:
He's complaining, in effect, that there are more than one URL for
identical
content, which is in fact generally a bad idea, but in this case, of
course,
You did get the EFF is pushing a Firefox plugin that has a rule that
redirects all WP accesses to the secure site part of that report, though,
right? This curve has probably already started to ramp; now might be a
good time for someone ops-y to be thinking about this.
I'd be concerned about
On Sat, Feb 12, 2011 at 10:26 PM, Chad innocentkil...@gmail.com wrote:
Yeah, secure.wikimedia.org's URL scheme isn't really friendly
to outsiders. Historically, this is because SSL certificates are
expensive, and there just wasn't enough money in the budget
to get more of them for the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
In article AANLkTikgDVs2zHMBzrd5dDkjsjadQVLmHjYpfjBhY+=n...@mail.gmail.com,
Aryeh Gregor simetrical+wikil...@gmail.com wrote:
On Sun, Feb 13, 2011 at 10:14 AM, River Tarnell r.tarn...@ieee.org wrote:
SSL certificates aren't that cheap, but only
On 13/02/11 11:54, Roan Kattouw wrote:
Bugzilla patches are another matter, yes, but I think making sure
patches get reviewed can be a Bugmeister task. We get relatively few
patches through Bugzilla these days anyway.
Maybe once 1.17 is released, we should focus on the bugzilla patch queue
MZMcBride z...@mzmcbride.com writes:
Does anyone know what the current status is?
I've talked to Hampton about getting up to speed. Hopefully I'll have
more information to share tomorrow.
--
Mark A. Hershberger
Bugmeister
Wikimedia Foundation
mhershber...@wikimedia.org
717.271.1084
Hi,
While working on fixing gadgets etc. I just noticed mediawiki.org
itself was not part of the first wave
(I confused it with metawiki I guess).
Is there any issues with switching to 1.17wmf1 before the rest goes
(say tonight or Monday) ? Currently
I'm writing some documentation but the
Roan Kattouw roan.katt...@gmail.com writes:
In the preparations for the 1.17 release I've seen lots of commits
that were several months old and only got reviewed because we decided
to work on a release. Ideally, every commit would be reviewed within a
few days of being committed, so the
On Sun, Feb 13, 2011 at 4:32 PM, Krinkle krinklem...@gmail.com wrote:
Is there any issues with switching to 1.17wmf1 before the rest goes
(say tonight or Monday) ? Currently
I'm writing some documentation but the 'new' versions of things don't
actually work on mw.org so it's
hard
On Sun, Feb 13, 2011 at 2:08 PM, Chad innocentkil...@gmail.com wrote:
On Sun, Feb 13, 2011 at 4:32 PM, Krinkle krinklem...@gmail.com wrote:
Is there any issues with switching to 1.17wmf1 before the rest goes
(say tonight or Monday) ? Currently
I'm writing some documentation but the 'new'
The problem with our current VCS is the sort of work-flow that has
developed around it.
But we can solve the work-flow problem without introducing an entirely
new VCS and disrupting everything for a month or so while people adjust
to the new system.
The solution I'm proposing is that we branch
I promise I don't have anything more to write today, but MZ pointed out
I neglected to finish my thought here:
Also, at some point I want to provide a better way — better than just
the complicated and confusing native Bugzilla interface — for collecting
bug reports. Having the input of a
On Sun, Feb 13, 2011 at 2:29 PM, Mark A. Hershberger
mhershber...@wikimedia.org wrote:
The problem with our current VCS is the sort of work-flow that has
developed around it.
But we can solve the work-flow problem without introducing an entirely
new VCS and disrupting everything for a
Hi Mark,
It is good to see people thinking about 1.18 already!
On Sun, Feb 13, 2011 at 11:29 PM, Mark A. Hershberger
mhershber...@wikimedia.org wrote:
The problem with our current VCS is the sort of work-flow that has
developed around it.
But we can solve the work-flow problem without
2011/2/14 Mark A. Hershberger mhershber...@wikimedia.org:
I promise I don't have anything more to write today
Actually, i enjoyed reading this string of emails from The 'Meister.
Also, at some point I want to provide a better way — better than just
the complicated and confusing native
To start out with catching up on patch review, I took a look over and
applied the patches on bug 23817, fixing wfObjectToArray() and FormatJson
for a case that broke certain parts of ForeignAPIRepo when PHP's native JSON
module wasn't present:
https://bugzilla.wikimedia.org/show_bug.cgi?id=23817
2011/2/14 Mark A. Hershberger mhershber...@wikimedia.org:
Also, at some point I want to provide a better way — better than just
the complicated and confusing native Bugzilla interface — for collecting
bug reports.
Oh, and of course, as much i love Bugzilla (really!), it has a very
serious
Well, if you want 1.18 released before 2012... ;)
Bryan
Well of course, Where would we be if we let the world end without a
new(ish) mediawiki release?
-Peachey
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
One-line fix for search suggestions for special pages where the alias
contains spaces (happens a lot more in non-English localizations).
Patch was submitted by Umherirrender in October 2010:
https://bugzilla.wikimedia.org/show_bug.cgi?id=25675
-- brion
Amir E. Aharoni amir.ahar...@mail.huji.ac.il writes:
he.wikipedia has a page for collecting bug reports, but since it's not
really structured, it's not really maintained.
Perhaps we could recruit some people from the he.wikipedia.org community
to take problems reported (via the localized
On Sun, Feb 13, 2011 at 4:40 PM, Mark A. Hershberger wrote:
Amir E. Aharoni writes:
he.wikipedia has a page for collecting bug reports, but since it's not
really structured, it's not really maintained.
Perhaps we could recruit some people from the he.wikipedia.org community
to take
Bryan Tong Minh bryan.tongm...@gmail.com writes:
The problem with our current VCS is the sort of work-flow that has
developed around it.
Can you be a bit more specific? What problems are you implying? I
think of some problems, but I don't know how they are consequences
from our workflow and
Mark A. Hershberger wrote:
Perhaps we could recruit some people from the he.wikipedia.org community
to
take problems reported (via the localized interface?) and reproduce
them or
act as a translator between developers and bug reporters?
There is already some infrastructure for this kind of
mhershber...@wikimedia.org (Mark A. Hershberger) writes:
The solution I'm proposing is that we branch 1.18 immediately after the
release of the 1.17 tarball.
I want to give credit where it is due. Although I haven't seen him
propose it here, this is, in fact, Robla's idea. He and I were
+1 to migrate to a DVCS
On Sun, Feb 13, 2011 at 8:38 PM, Mark A. Hershberger
mhershber...@wikimedia.org wrote:
mhershber...@wikimedia.org (Mark A. Hershberger) writes:
The solution I'm proposing is that we branch 1.18 immediately after the
release of the 1.17 tarball.
I want to give
Maybe we can make the bugathon part of the Berlin hackaton?
On Sun, Feb 13, 2011 at 4:03 PM, Ashar Voultoiz hashar+...@free.fr wrote:
On 13/02/11 11:54, Roan Kattouw wrote:
Bugzilla patches are another matter, yes, but I think making sure
patches get reviewed can be a Bugmeister task. We
+1 to migrate to a DVCS
Unless I'm mistaken no one has actually suggested doing that.
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On Sun, Feb 13, 2011 at 8:11 PM, Mark A. Hershberger
mhershber...@wikimedia.org wrote:
This workflow is different from a DVCS. Take Linux, for example. Linus
pulls code from several lieutenants. Anyone can set up a branch of the
Linux source code and commit to it, but to get Linus to ship
I think we can draw some inspiration from Mozilla's use of Bugzilla and
particular the format they are encourage users when submitting a bugreport:
1) Steps to reproduce
2) Expected result
3) Actual result
4) Reproducible (by bugreporter): always / sometimes
5) Version information, extensions
That's exactly my point :)
Most Firefox bugreporters are ordinary users so if they are able to report a
bug then Mediawiki users can do it as well because they are basically the
same group of Internet users. And again, my suggestion is not hard, it's
about giving ordinary people a number of
Op 14-02-11 05:01 schreef Daniel Friesen li...@nadir-seen-fire.com:
Ohh... if the translatewiki guys are looking for a dummy for
streamlining support for extensions based in git in preparation for a
git migration if we do so, I'd be happy to offer monaco-port up as a
existing extension (well,
46 matches
Mail list logo
