On 30/06/12 07:23, Gregory Varnum wrote:
> wikitech-announce will be used for occasional announcements on both MediaWiki
> and broader Wikimedia developer related news items
How does the new wikitech-announce compare with the existing
wikitech-ambassadors?
They both seem to have a similar scope/c
On Sat, Jun 30, 2012 at 7:23 AM, Gregory Varnum wrote:
> Greetings,
>
> Following discussions with Wikimedia developers more on the "fringe" and
> not as engaged in frequent IRC or mailing list conversations, the request
> for an announcements only mailing list came up. I wanted to let folks know
Greetings,
Following discussions with Wikimedia developers more on the "fringe" and not as
engaged in frequent IRC or mailing list conversations, the request for an
announcements only mailing list came up. I wanted to let folks know that this
list has been created and is ready for membership:
On Jun 29, 2012, at 6:36 PM, Petr Bena wrote:
> On Fri, Jun 29, 2012 at 4:22 PM, Antoine Musso wrote:
>
>>
>> Timo proposed a system where we would have a common configuration
>> directory, and one for production and another one for labs. Much like how
>> /etc/php5/ is organized on Debian syst
On Fri, Jun 29, 2012 at 7:23 PM, Platonides wrote:
> On 29/06/12 22:41, Marcin Cieslak wrote:
>> $ git reset --hard
>> HEAD is now at de13c31 Actually we have many contributors
>> $
>>
>> Chad, you made my day:)
>>
>> //Saper
>
> Great commit!
>
> https://gerrit.wikimedia.org/r/13449
>
Glad you e
Rob Lanphier wrote:
> Assuming we can either get these fixed, or agree they aren't blockers,
> I say we set a date and go. Should we plan on sometime in July (say a
> week or two after Wikimania)?
Your e-mail was unclear to me. It's difficult to tell whether you just
looked at the blockers of bug
Le 29/06/12 18:36, Petr Bena wrote:
> But that's a lot of hand work, if we really do this, we won't use
> gerrit at all, we just copy paste code from diffs by hand and insert
> it to some extra files. I would rather volunteer to sync branches
> rather than this creep work.
What hand work are you r
On 29/06/12 22:41, Marcin Cieslak wrote:
> $ git reset --hard
> HEAD is now at de13c31 Actually we have many contributors
> $
>
> Chad, you made my day:)
>
> //Saper
Great commit!
https://gerrit.wikimedia.org/r/13449
___
Wikitech-l mailing list
Wiki
On 29/06/12 21:42, Daniel Barrett wrote:
>> How can I prevent this conversion so ampersands (and presumably other
>> special characters) are preserved?
>
> Followup up my own question: StripState is not relevant here. It's the fact
> that it's a parser tag extension. Simply returning "&" in the
As seen on IRC:
https://github.com/ooyala/barkeep/wiki/Comparing-Barkeep-to-other-code-review-tools
//Saper
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
$ git reset --hard
HEAD is now at de13c31 Actually we have many contributors
$
Chad, you made my day:)
//Saper
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
In a parser tag callback, if I change this:
function myCallback($input, $argv, $parser) {
return '&';
}
to this:
function myCallback($input, $argv, $parser) {
return array('&', 'markerType' => 'nowiki');
}
shouldn't the second one cause a plain ampersand to be rendered, rather
> How can I prevent this conversion so ampersands (and presumably other special
> characters) are preserved?
Followup up my own question: StripState is not relevant here. It's the fact
that it's a parser tag extension. Simply returning "&" in the callback will
produce "&". Is there a way to sup
Ah hah! And the Tulsa cabal increases by one more! Another step on our (long
term...very long term) goal toward world domination, scheduled for the year
2320.
Unless we get distracted.
Hey, what's that shiny thing over there?...
Welcome, Matt!
PB
---
Philippe Beaud
WELCOME MATT!
On Fri, Jun 29, 2012 at 10:45 AM, Terry Chay wrote:
> Hello everyone,
>
> It’s with great pleasure that I’m announcing that Matt Walker has joined
> the Wikimedia Foundation as a Fundraising Engineer.
>
> Before joining us, Matt was a software engineer at Rockwell Collins
> Control
I have a parser tag extension that calls $parser->insertStripItem() to add some
text to StripState:
function myCallback($input, $argv, $parser) {
return $parser->insertStripState("this is a & test");
}
When the text renders on the wiki page, however, all ampersands have been
conve
Hello everyone,
It’s with great pleasure that I’m announcing that Matt Walker has
joined the Wikimedia Foundation as a Fundraising Engineer.
Before joining us, Matt was a software engineer at Rockwell Collins
Control Technologies developing “a DO-178B level A qualified Real-Time
Hi Helder,
Thanks for posting this to VPT, and relaying things back here.
Comments inline...
On Thu, Jun 28, 2012 at 5:26 PM, Helder . wrote:
> Anomie pointed out on enwiki's Village Pump[1] the problem with the
> Cite extension mentioned on
> https://bugzilla.wikimedia.org/show_bug.cgi?id=27478
On Fri, Jun 29, 2012 at 3:58 AM, Petr Bena wrote:
> Can we create a new branch which would be speedily merged when changes
> were done to it, so that we could check out on labs and apply the
> change there in order to test if patches submitted by devs works ok?
> Thanks to Antoine we use the same
But that's a lot of hand work, if we really do this, we won't use
gerrit at all, we just copy paste code from diffs by hand and insert
it to some extra files. I would rather volunteer to sync branches
rather than this creep work.
On Fri, Jun 29, 2012 at 4:22 PM, Antoine Musso wrote:
> Petr Bena w
Petr Bena wrote:
> Can we create a new branch which would be speedily merged when changes
> were done to it, so that we could check out on labs and apply the
> change there in order to test if patches submitted by devs works ok?
> Thanks to Antoine we use the same repository on beta project, but
>
Just stumbled over the "GetLocalURL::Internal"
(http://www.mediawiki.org/wiki/Manual:Hooks/GetLocalURL::Internal)
hook which was introduced in MW 1.19. This works pretty fine, just
doesn't work for page content but that can be done with the linker. It
works for pretty much everything else though, e
Imagine:
Some guy wants to deploy extension to Jamaican wikiversity and test it
on labs for 2 months before deploying to production. He create a patch
of config files and submit to gerrit. We merge it to test and
extension is immediately deployed on beta.
Another guy wants to test configuration c
If we are testing multiple items in same moment, replacing one test
with another is actually problem. That's what we need to somehow merge
right now. I hoped that gerrit could do it for us.
And we test multiple items there almost all time :)
On Fri, Jun 29, 2012 at 2:22 PM, Krinkle wrote:
> On J
On Jun 29, 2012, at 2:11 PM, Petr Bena wrote:
> Current idea:
>
> someone submit a config change
> this change is merged to testing branch
> we git pull on labs
> people test if change works ok and submit review to gerrit
> we merge to master branch or reject it
>
> On Fri, Jun 29, 2012 at 2:07
Current idea:
someone submit a config change
this change is merged to testing branch
we git pull on labs
people test if change works ok and submit review to gerrit
we merge to master branch or reject it
On Fri, Jun 29, 2012 at 2:07 PM, Petr Bena wrote:
> Yes but that would probably overwrite
Yes but that would probably overwrite any previous tests
On Fri, Jun 29, 2012 at 1:23 PM, Krinkle wrote:
> On Jun 29, 2012, at 1:04 PM, Chad wrote:
>
>> On Fri, Jun 29, 2012 at 6:58 AM, Petr Bena wrote:
>>> Can we create a new branch which would be speedily merged when changes
>>> were done to i
On Jun 29, 2012, at 1:04 PM, Chad wrote:
> On Fri, Jun 29, 2012 at 6:58 AM, Petr Bena wrote:
>> Can we create a new branch which would be speedily merged when changes
>> were done to it, so that we could check out on labs and apply the
>> change there in order to test if patches submitted by devs
On Fri, Jun 29, 2012 at 6:58 AM, Petr Bena wrote:
> Can we create a new branch which would be speedily merged when changes
> were done to it, so that we could check out on labs and apply the
> change there in order to test if patches submitted by devs works ok?
> Thanks to Antoine we use the same
Can we create a new branch which would be speedily merged when changes
were done to it, so that we could check out on labs and apply the
change there in order to test if patches submitted by devs works ok?
Thanks to Antoine we use the same repository on beta project, but
right now it's really hard
30 matches
Mail list logo
