For test purposes I wanted to clone the last commit only by using the
--depth option as in
/work/tmp/ # git clone --depth=10
https://gerrit.wikimedia.org/r/p/mediawiki/core.git
and got this error message:
Initialized empty Git repository in /work/tmp/core/.git/
*error: RPC failed; result=22,
On Fri, Apr 13, 2012 at 3:56 PM, Petr Bena benap...@gmail.com wrote:
That was just an example, interesting are of course even checkuser
accounts and such. I don't see any reason why system which notify you
that someone is trying to login as you is something bad for stewards.
That feature would
Siebrand changed the status of MediaWiki.r114878 to fixme and commented it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114878#c32666
Old Status: new
New Status: fixme
Commit summary for MediaWiki.r114878:
* Catch bad metadata.ini files earlier so we don't have PHP giving us
Yes, that is what I just tried to propose in second email :-) I see I
am not the only one who believe we need it
On Fri, Apr 13, 2012 at 8:33 AM, John Vandenberg jay...@gmail.com wrote:
On Fri, Apr 13, 2012 at 3:56 PM, Petr Bena benap...@gmail.com wrote:
That was just an example, interesting
Στις 13-04-2012, ημέρα Παρ, και ώρα 12:49 +1000, ο/η Andrew Garrett
έγραψε:
On Wed, Apr 4, 2012 at 6:25 PM, Petr Bena benap...@gmail.com wrote:
An account with sysop rights cannot do that much damage anyway.
Deleting a page does no more damage than deleting a paragraph in an
existent
No doubt that any user account compromised would be unfortunate and
would also mean that developers didn't make the software secure
enough. On one side there are needs for big restriction on community
developers from being able to access resources (not just shell access
is restricted a lot) but it
Nikerabbit changed the status of MediaWiki.r114872 to ok
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114872
Old status: new
New status: ok
Commit summary for MediaWiki.r114872:
Update group IDs to improve exports.
___
On Thu, 12 Apr 2012 23:32:03 -0700, Thomas Gries m...@tgries.de wrote:
For test purposes I wanted to clone the last commit only by using the
--depth option as in
/work/tmp/ # git clone --depth=10
https://gerrit.wikimedia.org/r/p/mediawiki/core.git
and got this error message:
Initialized
On Thu, 12 Apr 2012 12:54:41 -0700, Arthur Richards
aricha...@wikimedia.org wrote:
On Thu, Apr 12, 2012 at 12:43 PM, Daniel Friesen
li...@nadir-seen-fire.comwrote:
Might this be a browser caching issue, not a server caching issue?
Yeah, I believe so.
As a temporary hack you could try
Hi,
Before posting a bug for this, I thought I should pop a question to
see if somebody hasn't done this already.
Some of the content partners I'm in contact with are not really happy
about being attributed on the talk page and/or the history of the
article. I was thinking that we could have an
How is this any differnt from using E:Cite (aka ref/ref) as is?
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 13 April 2012 04:52, Rob Lanphier ro...@wikimedia.org wrote:
Hi everyone,
During the 1.19 cycle, there were some namespace names that were changed
and then reverted shortly before deployment. We're about to deploy
1.20wmf1 to a lot of international wikis on Wednesday of next week, and I'm
În data de 13 aprilie 2012, 11:56, K. Peachey p858sn...@gmail.com a scris:
How is this any differnt from using E:Cite (aka ref/ref) as is?
ref/ref is appropriate for small chunks of text, maybe a
paragraph, but not for whole sections or articles (because the text
can change and the attributions
On Fri, Apr 13, 2012 at 05:53, Strainu strain...@gmail.com wrote:
Hi,
Before posting a bug for this, I thought I should pop a question to
see if somebody hasn't done this already.
Some of the content partners I'm in contact with are not really happy
about being attributed on the talk page
I have no knowledge of Lua, but I don't see what is problem with print
here, the function print is supposed to print output to output device
in most of programming languages, just as in this case, so I don't
understand why we should want to use return (which is supposed to
return some data /
Tim, is there any code publicly available for the new extension you
talk about? I would like to see it, if it exist (and isn't anything
secret).
On Fri, Apr 13, 2012 at 2:12 PM, Petr Bena benap...@gmail.com wrote:
I have no knowledge of Lua, but I don't see what is problem with print
here, the
On 13 April 2012 13:12, Petr Bena benap...@gmail.com wrote:
I have no knowledge of Lua, but I don't see what is problem with print
here, the function print is supposed to print output to output device
in most of programming languages, just as in this case, so I don't
understand why we should
On 13 April 2012 13:45, Tim Starling tstarl...@wikimedia.org wrote:
At the moment, in the Lua support extension we have been developing,
wikitext is output to the wiki via the return value of a function. For
example in wikitext you would have:
{{#invoke:MyModule|myFunction}}
Then in
În data de 13 aprilie 2012, 14:57, Helder helder.w...@gmail.com a scris:
See also bug 27629 (Collection extension needs some way to credit
original authors of a work[1]) which depends on bug 28064 (Summary of
page editors/authors[2]) and has links to a thread on enwiki's Village
pump[3].
MW needs full etag support, with hooks for extensions. Without it, we can't
widely support caching in the case you've outlined.
Different browsers handle the Vary header differently. Some treat Varies
as don't cache. Chrome (possibly other webkit browsers) treats it as a
marker to revalidate
Does anyone have any thoughts on return versus print generally? Are
there other reasons we would choose one over the other?
From a language perspective, I would much prefer return values instead
of side effects, even if those side effects could be converted into a
return value with a special
On Fri, Apr 13, 2012 at 09:45:52PM +1000, Tim Starling wrote:
Does anyone have any thoughts on return versus print generally?
If you do go with the print solution, someone will eventually request
something along the lines of PHP's output buffering functions[1] so they
don't have to rewrite
În data de 13 aprilie 2012, 12:02, Niklas Laxström
niklas.laxst...@gmail.com a scris:
Since when is consensus required for software or localisation changes?
Niklas, are you having a bad day today or are you always so
inconsiderate to the main users of the software you write? A namespace
name
On 13.04.2012 16:12, Petr Bena wrote:
I have no knowledge of Lua, but I don't see what is problem with print
here, the function print is supposed to print output to output device
in most of programming languages, just as in this case, so I don't
understand why we should want to use return (which
On 28/03/12 12:17, Antoine Musso wrote:
Le 28/03/12 04:37, Ryan Lane a écrit :
It already supports sending to multiple channels. I can't go into
details right now, but I'll follow up on this later with more info.
That message remembers meof Fermat last theorem :-)
You can just separate the
On 13/04/12 16:19, Gabriel Wicke wrote:
Does anyone have any thoughts on return versus print generally? Are
there other reasons we would choose one over the other?
From a language perspective, I would much prefer return values instead
of side effects, even if those side effects could be
Khorn (WMF) changed the status of Wikimedia.r1605 to ok
URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1605
Old status: new
New status: ok
Commit summary for Wikimedia.r1605:
Added fee, net, payment_submethod, original_currency and original_gross to $msg.
On 13/04/12 10:29, Daniel Friesen wrote:
By the way, using --depth only saves you disk space
(which is a trivially small amount,
I disagree, 18M vs 341M is quite noticeable.
which linked repositories can cut back on as well).
Only if you're cloning on the same filesystem. We're talking about
On Fri, Apr 13, 2012 at 2:32 AM, Thomas Gries m...@tgries.de wrote:
For test purposes I wanted to clone the last commit only by using the
--depth option as in
/work/tmp/ # git clone --depth=10
https://gerrit.wikimedia.org/r/p/mediawiki/core.git
and got this error message:
Initialized
Nikerabbit changed the status of MediaWiki.r114651 to fixme and commented
it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114651#c32667
Old Status: new
New Status: fixme
Commit summary for MediaWiki.r114651:
fix bug 35643 plus some extra cleanup
Nikerabbit's comment:
Please add
+1 to all the points for using return values.
If we have to implement an output buffer in Lua, we have probably
failed. Output buffering is is messy and prone to error. It's certainly not
a good design from a usability standpoint, and it's generally messy to deal
with.
Template invocations
On Fri, Apr 13, 2012 at 7:19 AM, Gabriel Wicke wi...@wikidev.net wrote:
From a language perspective, I would much prefer return values instead
of side effects, even if those side effects could be converted into a
return value with a special print implementation.
I think I agree with Gabriel
Hey,
Back in the old days, when we were still using SVN, we had this svn auto
props id thing in API modules used in the getVersion method. Is there a git
equivalent thing we should use now?
Cheers
--
Jeroen De Dauw
http://www.bn2vs.com
Don't panic. Don't be evil.
--
On Fri, Apr 13, 2012 at 1:37 PM, Jeroen De Dauw jeroended...@gmail.com wrote:
Hey,
Back in the old days, when we were still using SVN, we had this svn auto
props id thing in API modules used in the getVersion method. Is there a git
equivalent thing we should use now?
No. There are no such
On Fri, Apr 13, 2012 at 9:27 AM, Platonides platoni...@gmail.com wrote:
On 28/03/12 12:17, Antoine Musso wrote:
Le 28/03/12 04:37, Ryan Lane a écrit :
It already supports sending to multiple channels. I can't go into
details right now, but I'll follow up on this later with more info.
That
Such extension is very simple to make.
You register a tag extension, and on parse you return something.
However, you store the parsed content in page_props. You could also
store it in ParserOutput, page_props seems cleaner, although it would be
unstructured data, anyway.
What kind of contents
On 13/04/12 09:30, Petr Bena wrote:
If I wanted to cause harm to an editing community, one of the better ways
might be ... sounds dangerous from someone who has access to servers :-)
He is a puppetmaster who wants nothing from his puppets? :)
http://xkcd.com/792/
now filed as
https://bugzilla.wikimedia.org/show_bug.cgi?id=35949
*Bug 35949* https://bugzilla.wikimedia.org/show_bug.cgi?id=35949
-Shallow clones fail with errors: git clone --depth 1 fails with error:
RPC failed; result=22, HTTP code = 500
___
On 13/04/12 19:18, Rob Lanphier wrote:
I imagine there's going to be a lot of cut-and-paste going on, so
if we can establish best practices early (keeping a close eye on how it's
being used), we can introduce some good genetic stock into future Lua
scripts.
Imagine my shock when I first read
On 13 April 2012 03:49, Andrew Garrett agarr...@wikimedia.org wrote:
Now, there are things that sysops can do that aren't so easily reversible.
You could surreptitiously add site JS that captured tokens from checkusers
and released large amounts of sensitive data, so it's not exactly without
On 04/13/2012 12:47 AM, Ole Palnatoke Andersen wrote:
Answers to both further down.
On Fri, Apr 13, 2012 at 4:50 AM, Andrew Garrett agarr...@wikimedia.orgwrote:
On Thu, Apr 5, 2012 at 8:38 AM, Sumana Harihareswara
suma...@wikimedia.orgwrote:
Ole, yay! This is cool. Is it ok to forward
Pgehres (WMF) posted a comment on Wikimedia.r1606.
URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1606#c32668
Commit summary for Wikimedia.r1606:
Adding parallel thank you message generation for recurring contributions.
Terrible violation of DRY, but right now its simplest and does
On Fri, Apr 13, 2012 at 9:24 PM, Sumana Harihareswara suma...@wikimedia.org
wrote:
On 04/13/2012 12:47 AM, Ole Palnatoke Andersen wrote:
Answers to both further down.
On Fri, Apr 13, 2012 at 4:50 AM, Andrew Garrett agarr...@wikimedia.org
wrote:
On Thu, Apr 5, 2012 at 8:38 AM, Sumana
Hello,
Some people have reported that since the new version of git-review the
had issue submitting patches. The symptom is:
someone hack
attempt to send the work by using `git-review`
Complaint:
You have more than one commit that you are about to submit.
The oustanding commits are:
MaxSem changed the status of MediaWiki.r113190 to fixme and commented it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113190#c32669
Old Status: ok
New Status: fixme
Commit summary for MediaWiki.r113190:
[SyntaxHighlight GeSHi] Use code and pre instead of span and div to
allow
Kaldari changed the status of MediaWiki.r113667 to ok
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113667
Old status: new
New status: ok
Commit summary for MediaWiki.r113667:
followup to -r113451 - add documentation, pagetriage tags and fix data
compilation queries
On Fri, 13 Apr 2012 13:33:43 -0700, Antoine Musso hashar+...@free.fr
wrote:
Hello,
Some people have reported that since the new version of git-review the
had issue submitting patches. The symptom is:
someone hack
attempt to send the work by using `git-review`
Complaint:
You have more
Kaldari posted a comment on MediaWiki.r114891.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114891#c32670
Commit summary for MediaWiki.r114891:
Set svn:keywords property to Id
Kaldari's comment:
well, that didn't work.
___
+1 for only supporting return values. The case where one needs
thousands of string concats is pretty rare and can be worked around,
and seems like the only reasonable argument in favour of using print.
One exit point per function is much easier to read than juggling
possible scattered print
Kaldari changed the status of MediaWiki.r113451 to ok
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113451
Old status: new
New status: ok
Commit summary for MediaWiki.r113451:
PageTriage new tables, getMetaData API and database access file
Re-adding the list, as this is of public interest.
În data de 13 aprilie 2012, 19:42, Niklas Laxström
niklas.laxst...@gmail.com a scris:
I do consider users (at least one, me!).
Glad to hear that, but you're not the main user of either
translatewiki or mediawiki in general.
If we must
În data de 13 aprilie 2012, 21:15, Platonides platoni...@gmail.com a scris:
What kind of contents would the tags have? An name per line? What if
there should be something besides the name (eg. a url or email)?
I was thinking the tags should contain all the attributions, therefore
having a
Kaldari posted a comment on MediaWiki.r114891.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114891#c32671
Commit summary for MediaWiki.r114891:
Set svn:keywords property to Id
Kaldari's comment:
actually, I guess it did.
___
Kaldari posted a comment on MediaWiki.r113451.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113451#c32672
Commit summary for MediaWiki.r113451:
PageTriage new tables, getMetaData API and database access file
Kaldari's comment:
Id added in r114897.
Kaldari changed the status of MediaWiki.r113451 to resolved
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113451
Old status: ok
New status: resolved
Commit summary for MediaWiki.r113451:
PageTriage new tables, getMetaData API and database access file
Platonides posted a comment on MediaWiki.r114891.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114891#c32673
Commit summary for MediaWiki.r114891:
Set svn:keywords property to Id
Platonides's comment:
It did.
___
MediaWiki-CodeReview
Kaldari changed the status of MediaWiki.r114222 to ok
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114222
Old status: new
New status: ok
Commit summary for MediaWiki.r114222:
Add method to generate PageTriage dashboard data and table for logging
pagetriage activity
Op 14 apr. 2012 om 00:01 heeft Strainu strain...@gmail.com het volgende
geschreven:
Re-adding the list, as this is of public interest.
Wow. It's generally considered to be pretty rude to just publish a private
reply to a public list. I'm assuming good faith, but please ask next time,
would
Khorn (WMF) changed the status of Wikimedia.r1606 to ok and commented it.
URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1606#c32674
Old Status: new
New Status: ok
Commit summary for Wikimedia.r1606:
Adding parallel thank you message generation for recurring contributions.
Terrible
Khorn (WMF) changed the status of Wikimedia.r1607 to ok
URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1607
Old status: new
New status: ok
Commit summary for Wikimedia.r1607:
Removing duplicated code blocks.
___
MediaWiki-CodeReview
Hi Niklas,
Thanks for the detailed response. I think you addressed a lot of my
concerns.
Comments inline:
On Fri, Apr 13, 2012 at 2:02 AM, Niklas Laxström
niklas.laxst...@gmail.comwrote:
Two concerns:
1. Do the new namespace names have community consensus? What I've heard
though the
Kaldari posted a comment on MediaWiki.r114419.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114419#c32675
Commit summary for MediaWiki.r114419:
added article delete hook, deletion method
added stubs for unit tests
removed crufty code from our previous start on this feature
Kaldari changed the status of MediaWiki.r114419 to fixme
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114419
Old status: new
New status: fixme
Commit summary for MediaWiki.r114419:
added article delete hook, deletion method
added stubs for unit tests
removed crufty code from our
Kaldari changed the status of MediaWiki.r114431 to ok and commented it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114431#c32676
Old Status: new
New Status: ok
Commit summary for MediaWiki.r114431:
provided metadata to provided page list
Kaldari's comment:
pre
if (
Kaldari changed the status of MediaWiki.r114494 to ok
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114494
Old status: new
New status: ok
Commit summary for MediaWiki.r114494:
fixed list view so it runs with debug=false too
___
Kaldari changed the status of MediaWiki.r114496 to ok
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114496
Old status: new
New status: ok
Commit summary for MediaWiki.r114496:
really correct api path this time.
___
MediaWiki-CodeReview
Kaldari changed the status of MediaWiki.r114495 to resolved
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114495
Old status: new
New status: resolved
Commit summary for MediaWiki.r114495:
correctly look up the api path
___
Kaldari changed the status of MediaWiki.r114534 to ok
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114534
Old status: new
New status: ok
Commit summary for MediaWiki.r114534:
simpler API path
followup to r114496
___
MediaWiki-CodeReview
Kaldari changed the status of MediaWiki.r114533 to ok
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114533
Old status: new
New status: ok
Commit summary for MediaWiki.r114533:
bytes should have a PLURAL.
followup to r114501
___
Kaldari changed the status of MediaWiki.r114501 to fixme and commented it.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114501#c32677
Old Status: new
New Status: fixme
Commit summary for MediaWiki.r114501:
added actual metadata to the template, proper i18n strings
Kaldari's
Just spent some time updating dippy-bird. Now using 'gerrit review' (thanks
Chad) and now supports code review, abandon, submit, and restore operations
on changesets in gerrit.
This has already proved super handy for me when I've needed to do do a
bulk-abandon on changesets.
Take it for a spin,
Krinkle posted a comment on MediaWiki.r113190.
URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/113190#c32678
Commit summary for MediaWiki.r113190:
[SyntaxHighlight GeSHi] Use code and pre instead of span and div to
allow skins to universally style these without requiring local wikis
Awesome work Arthur!
— Patrick
On Fri, Apr 13, 2012 at 5:32 PM, Arthur Richards
aricha...@wikimedia.org wrote:
Just spent some time updating dippy-bird. Now using 'gerrit review' (thanks
Chad) and now supports code review, abandon, submit, and restore operations
on changesets in gerrit.
Pgehres (WMF) changed the status of Wikimedia.r1615 to ok
URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1615
Old status: new
New status: ok
Commit summary for Wikimedia.r1615:
Evil assignment bug making every rebuilt transaction look like a recurring
transaction and grossly
On 14/04/12 00:19, Gabriel Wicke wrote:
I am no Lua expert, but would guess that the usual
collect-in-list-and--finally-join method can avoid the performance
penalty in Lua too.
Yes, it works. With short strings, the memory overhead of the table
elements can become excessive, so it makes sense
On 13/04/12 22:19, Petr Bena wrote:
Tim, is there any code publicly available for the new extension you
talk about? I would like to see it, if it exist (and isn't anything
secret).
Yes, it is the Scribunto extension in Git. You can get the latest
version with:
git clone
76 matches
Mail list logo
