2011/3/28 Tim Starling tstarl...@wikimedia.org:
Who's with me?
I don't really have a good idea of what would need to change to
support HipHop, but if the changes aren't to intrusive I'm all for it.
If we decide to do this, we should also decide when to start and when
we want to have HPHP
Two things:
(i) I'd really hope that subclassing would be very rare here. I don't think
this will be much of an issue though.
(ii) Also, it would be nice if developers could all have hiphop running on
their test wikis, so that code that's broken on hiphop isn't committed in
ignorance. The only
On 28/03/11 17:36, Roan Kattouw wrote:
2011/3/28 Tim Starling tstarl...@wikimedia.org:
Who's with me?
I don't really have a good idea of what would need to change to
support HipHop, but if the changes aren't to intrusive I'm all for it.
If we decide to do this, we should also decide when
I'll be honest, I was thinking of this being part of wikicore; not
just another extension.
I think media support in core would be a good idea.
TIA
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
On 26/03/11 14:56, Mark A. Hershberger wrote:
So, other than switching to the mythical GIT, where all is rainbows and
roses, what can we do to improve code review now?
It's no mystery. After the 1.17 deployment, the team that was doing
code review was disassembled. If you want code review to
Good morning.
If many people work in the process of verification and selection of
items, what is the proper way to record the list csv without the
following problems occur:
1) Repeat entries (Someone reviewed the same article because he did
not know that was already in the list)
2) Create a
2011/3/28 Tim Starling tstarl...@wikimedia.org:
By definition, our volunteer developers have lives outside of
MediaWiki. We have to fit in with their schedules. I don't think we
should give them a kick in the teeth just because they committed
something on Sunday and have to go to school on
On Fri, Mar 25, 2011 at 11:56 PM, Mark A. Hershberger
mhershber...@wikimedia.org wrote:
As far as I can see, the main reason that people think code review
works better under GIT is because the committer is responsible for
getting xyr[2] code reviewed *before* it is merged. The committer is
On Sun, Mar 27, 2011 at 11:21 PM, Tim Starling tstarl...@wikimedia.org wrote:
Facebook now write their PHP code to target HipHop exclusively, so by
trying to write code that works on both platforms, we'll be in new
territory, to some degree. Maybe that's scary, but I think it can work.
What
On Mar 28, 2011, at 5:28 PM, Aryeh Gregor wrote:
... and Facebook ignores that and adds what
it thinks would be useful?
Facebook already has features Zend does not:
https://github.com/facebook/hiphop-php/blob/master/doc/extension.new_functions
Stuff like:
* Parallel RPC - MySQL, HTTP, ..
*
Hi
I am interested in the Captcha extension project in GSOC'11. But I am
unable to find a mentor ( potential mentor ) who can help me out in my
problem related to captchas.
Please provide me with contact details of someone who will be
potentially mentoring this project.
Thank you.
On 29/03/11 01:28, Aryeh Gregor wrote:
What happens when the feature lists start diverging, because Zend adds
what it thinks would be useful and Facebook ignores that and adds what
it thinks would be useful? Then we can't use any new features from
either.
We can use features from both, using
On Mon, Mar 28, 2011 at 10:28 AM, Aryeh Gregor
simetrical+wikil...@gmail.com wrote:
On Mon, Mar 28, 2011 at 9:42 AM, Chad innocentkil...@gmail.com wrote:
I also don't know if they've actually merged the 32bit work into their
mainline yet--I know a volunteer was working on it. If they're lacking
On 03/26/2011 12:03 AM, Andrew Garrett wrote:
On Thu, Mar 24, 2011 at 1:46 AM, Todlistac...@gmail.com wrote:
This is a fork of this thread:
http://www.gossamer-threads.com/lists/wiki/wikitech/228949?page=last
Is there a possibility that I could instead (easily) merge the handful
of
Hi
I was planning to make an api sandbox for mediawiki as a part of gsoc 2011.
while going through mediawiki documentation, i found that many functions
needed POST rather than GET requests. i am planning for flickr like api
On 03/26/2011 06:54 AM, ankit garg wrote:
Hi All,
My name is ankit. I am applying for Gsoc 2011 .I have prepared an
initial draft for the proposal(copied below) .I have taken feedback from my
mentor Yaron Koren on this. Please feel free to give your comments ..
Thanks
[snip]
Project
On Mon, Mar 28, 2011 at 5:39 PM, SALIL P A salilpa...@gmail.com wrote:
to make the api sandbox really useful, it ideally should have automatic php
code generation too ( i don't know if it is overambitious ). for example for
login and logout, user can just give his userid and password and the
thanks bryan :)
Salil P A
On Mon, Mar 28, 2011 at 9:40 PM, Bryan Tong Minh
bryan.tongm...@gmail.comwrote:
On Mon, Mar 28, 2011 at 5:39 PM, SALIL P A salilpa...@gmail.com wrote:
to make the api sandbox really useful, it ideally should have automatic
php
code generation too ( i don't
On 03/24/2011 07:17 PM, K. Peachey wrote:
On Fri, Mar 25, 2011 at 7:40 AM, Sumana Harihareswarasuma...@panix.com
wrote:
There's no point in having our GSoC applicants wasting time working on
proposals that we aren't really interested in
Who is we the wikimedia foundation? the medawiki
On 11-03-28 08:09 AM, Tod wrote:
On 03/26/2011 12:03 AM, Andrew Garrett wrote:
On Thu, Mar 24, 2011 at 1:46 AM, Todlistac...@gmail.com wrote:
This is a fork of this thread:
http://www.gossamer-threads.com/lists/wiki/wikitech/228949?page=last
Is there a possibility that I could instead
2011/3/28 Bryan Tong Minh bryan.tongm...@gmail.com:
That would be the best way to go. You really don't want to do this
manually. Every API modules has a function getFinalParamDescription()
which will give you the parameter description, including the defaults
and the variable type. Best look at
On 11-03-28 12:44 AM, Tim Starling wrote:
On 28/03/11 17:36, Roan Kattouw wrote:
2011/3/28 Tim Starlingtstarl...@wikimedia.org:
Who's with me?
I don't really have a good idea of what would need to change to
support HipHop, but if the changes aren't to intrusive I'm all for it.
If we decide
I developed a corresponding sync. tool and a search engine (already public)
which works fine :-).
Hope the sync. tool will be public soon.
c u stevie www.webserver-management.de
-Ursprüngliche Nachricht-
Von: wikitech-l-boun...@lists.wikimedia.org
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Not sure this is the right place, but:
Are the Vector skin versions of the external link icons [1] on Commons
anywhere? I couldn't find them when I looked, and I'm not entirely sure
where to find them in order to upload [and I don't want to dupe
On 03/28/2011 3:18 PM, Stefan Werthmann wrote:
I developed a corresponding sync. tool and a search engine (already public)
which works fine :-).
Hope the sync. tool will be public soon.
Could you point me to it?
c u stevie www.webserver-management.de
-Urspr�ngliche Nachricht-
Op 27-3-2011 23:18, Roan Kattouw schreef:
2011/3/27 Schneelockeschneelo...@gmail.com:
Hi everyone,
did the SSL certificate for secure.wikimedia.org expire?
It did, yes. Informing our ops department, they should be able to sort
this out quickly.
Time for someone to implement
Thanks to those who have been working on these bugs. Brion has done an
awesome job of closing out most of the known installer issues, for which
I am extremely thankful.
Also, following Brion's suggestion that we not make PostgreSQL a tarball
blocker and the consensus of IRC participants, we're
On Mon, Mar 28, 2011 at 7:20 AM, Aryeh Gregor simetrical+wikil...@gmail.com
wrote:
If, as Tim says, Wikimedia developers were un-assigned from code
review after the 1.17 deployment, *that* is the problem that needs to
be fixed. We need a managerial decision that all relatively
experienced
In MediaWiki there are two preferences: Disable AJAX suggestions and
Enable enhanced search suggestions (Vector skin only).
They are problematic for several reasons:
1. Most average users don't know what AJAX is. It should be just
called search suggestions.
2. The first option says Disable, but
011/3/28 Douglas Gardner douglas.gard...@wikinewsie.org:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Not sure this is the right place, but:
Are the Vector skin versions of the external link icons [1] on Commons
anywhere? I couldn't find them when I looked, and I'm not entirely sure
where
In the search preferences i can put a number in Context per line. I
tried changing it on Wikipedia and no matter what i put there, nothing
seems to change on the results page.
It it supposed to do anything at all? If it doesn't do anything on
Wikipedia, then why is the preference still there?
--
On Mar 28, 2011, at 1:31 PM, Rob Lanphier wrote:
You say that as though this were obvious and uncontroversial. The reason
why we've been dancing around this issue is because it is not.
Right now, we have a system whereby junior developers get to commit whatever
they want, whenever they
Wilfredo Rodriguez wrote:
Good morning.
If many people work in the process of verification and selection of
items, what is the proper way to record the list csv without the
following problems occur:
1) Repeat entries (Someone reviewed the same article because he did
not know that was
On Mon, Mar 28, 2011 at 10:47 AM, Tim Starling tstarl...@wikimedia.org wrote:
We can use features from both, using function_exists(), like what we
do now with PHP modules.
Well, yes, if there's some reasonable fallback. It doesn't work for
features that are useless if you have to write a
Tod wrote:
I'm working with a group that has customized their mediawiki
installation so that they can create multiple wiki instances, each with
their own database, that have no knowledge of each others existence.
This was done for security and privacy reasons.
The dumpBackup.php utility
Tim Starling wrote:
If the code review manpower is there, we can be friendly and
encouraging to our developers, not threaten them with a revert unless
they can make at least one developer be their friend within seven days.
The WMF really is central in this, because we have a policy of hiring
Tim Starling wrote:
I think we should migrate MediaWiki to target HipHop [1] as its
primary high-performance platform. I think we should continue to
support Zend, for the benefit of small installations. But we should
additionally support HipHop, use it on Wikimedia, and optimise our
Trevor Parscal wrote:
On Mar 28, 2011, at 1:31 PM, Rob Lanphier wrote:
You say that as though this were obvious and uncontroversial. The reason
why we've been dancing around this issue is because it is not.
Right now, we have a system whereby junior developers get to commit whatever
they
On 29/03/11 11:26, MZMcBride wrote:
Long ago I lost track of who's in charge of what, but I'm told there is some
sort of hierarchy in place in the tech department. Who's empowered to start
assigning people to review code in a reasonable timeframe? Like Aryeh, I
find this entire thread a bit
Rob Lanphier ro...@wikimedia.org wrote in message
news:AANLkTi=lgjrjj-gjx+_sdb0wpc62kptpoxbr7jkm8...@mail.gmail.com...
On Mon, Mar 28, 2011 at 7:20 AM, Aryeh Gregor
simetrical+wikil...@gmail.com
wrote:
If, as Tim says, Wikimedia developers were un-assigned from code
review after the 1.17
Tim Starling tstarl...@wikimedia.org writes:
On 26/03/11 14:56, Mark A. Hershberger wrote:
If code is to survive past a week in the repository, it has to be
reviewed.
If you want to make a commit that depends on un-reviewed code, you have
to find someone to review it. Otherwise, your
On 29/03/11 09:40, Aryeh Gregor wrote:
On Mon, Mar 28, 2011 at 10:47 AM, Tim Starling tstarl...@wikimedia.org
wrote:
We can use features from both, using function_exists(), like what we
do now with PHP modules.
Well, yes, if there's some reasonable fallback. It doesn't work for
features
On Mon, Mar 28, 2011 at 4:31 PM, Rob Lanphier ro...@wikimedia.org wrote:
Right now, we have a system whereby junior developers get to commit whatever
they want, whenever they want. Under the system you outline, the only
remedy we have to the problem of falling behind is to throw more senior
In case no one has mentioned this, changing the DOCTYPE has a pretty
huge effect on how CSS gets rendered. Wikimedia's current DOCTYPE (XHTML
transitional) maps to almost standards mode or limited quirks mode
in Firefox, Safari, Chrome, Opera, IE8 and IE9. Changing to !DOCTYPE
html will switch
Ryan Kaldari wrote:
In case no one has mentioned this, changing the DOCTYPE has a pretty
huge effect on how CSS gets rendered. Wikimedia's current DOCTYPE (XHTML
transitional) maps to almost standards mode or limited quirks mode
in Firefox, Safari, Chrome, Opera, IE8 and IE9. Changing to
On 3/28/11 7:53 PM, Chad wrote:
It *was* reverted, it hasn't been deployed again since.
Well, it still seems to be in place on truck, which is why I'm getting
CSS bug reports. Can someone revert it on trunk as well?
The brief discussion of the CSS rendering-mode issue on Mediawiki.org
seems
On Mon, Mar 28, 2011 at 11:11 PM, Ryan Kaldari rkald...@wikimedia.org wrote:
On 3/28/11 7:53 PM, Chad wrote:
It *was* reverted, it hasn't been deployed again since.
Well, it still seems to be in place on truck, which is why I'm getting CSS
bug reports. Can someone revert it on trunk as well?
On Tue, Mar 29, 2011 at 1:11 PM, Ryan Kaldari rkald...@wikimedia.org wrote:
Well, it still seems to be in place on truck, which is why I'm getting
CSS bug reports. Can someone revert it on trunk as well?
The brief discussion of the CSS rendering-mode issue on Mediawiki.org
seems to be nicely
On Tue, Mar 29, 2011 at 1:11 PM, Ryan Kaldari rkald...@wikimedia.org wrote:
Well, it still seems to be in place on truck, which is why I'm getting
CSS bug reports. Can someone revert it on trunk as well?
Which bug reports? can you link to some in Bz or the like please?
So which rendering mode should I be vetting CSS for? Strict or limited
quirks? Some of the CSS that I review is specifically tweaked for
limited quirks since that's what the Wikimedia sites are running in.
Honestly, I don't know all of the problems that this change will cause.
I imagine it
50 matches
Mail list logo
