date:20130212

Re: [Wikitech-l] Stable PHP API for MediaWiki ?

2013-02-12 Thread Antoine Musso

Le 11/02/13 19:58, vita...@yourcmc.ru a écrit :
>> 1) removal of global $action
>> 2) removal of Xml::hidden()
>> 3) broken Output::add() (had to migrate to resource loader)
>> 4) various parser tag bugs
>> 5) removal of MessageCache::addMessage()
>> 6) removal of ts_makeSortable() (javascript)
>> 7) brokage of WikiEditor adaptation
>> 8) MediaWiki:common.js no more loading by default (security)
>> 9) addHandler() javascript broken in IE8
> 
> Most of these were deprecations, am I correct?
> 

I guess so.  Probably methods we simply removed instead of deprecating
them like we are doing nowadays.

-- 
Antoine "hashar" Musso


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Font at dv.wikipedia and dv.wiktionary

2013-02-12 Thread oәuɐႡɔsʇnәp nɐႡsn

Hello. The fonts at Dhivehi Wikipedia and Wiktionary are not webfonts. If 
possible could the fonts be changed to Faruma which can be downloaded from 
here: 
http://bazaar.launchpad.net/~mvishah/ttf-dhivehi-fonts/trunk/view/head:/ttf-thaana-fonts/faruma.ttf
 . Originally this issue was raised at 
http://dv.wikipedia.org/wiki/User_talk:Glacious#Fonts by User:Vituzzu. I have 
tried http://www.mediawiki.org/wiki/Extension:WebFonts#Preparing_webfonts but 
to no result. Can someone help me regarding this matter.
Links: dv.wikipedia.orgdv.wiktionary.org
MediaWiki - 1.21wmf8 (17a7840)PHP - 5.3.10-1ubuntu3.4+wmf1 
(apache2handler)MySQL - 5.1.53-wm-log
I have posted this question at the MediaWiki support desk here: 
http://www.mediawiki.org/wiki/Thread:Project:Support_desk/Font_at_dv.wikipedia_and_dv.wiktionary
 and User:MarkAHershberger directed me to 
https://bugzilla.wikimedia.org/show_bug.cgi?id=42812 but no one is responding 
in there. So he told me to mail to this list.
Regards,Ushau 
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Announcement: Ed Sanders joins Wikimedia as Visual Editor Software Engineer

2013-02-12 Thread Platonides

Welcome Ed!



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-12 Thread Platonides

On 12/02/13 06:26, Brian Wolff wrote:
> For subpages to really fill this use case I think the page title would have
> to show only (or primarily emphasize) the subpage name instead of the full
> page name.

I think it has been brought up in the past, there may be an extension
doing that.


> Also it sounds like in such a use case, one would want links to be relative
> to the current path first. If on page a/b/c you would want [[foo]] to link
> to a/b/foo if it exists and link to just foo if that page does not exist.

And where should the red-link send you to?
That may be more confusing for some users.

We have ../ links, perhaps add also ./ ?



___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] deployment of the first phase of Wikidata on enwp

2013-02-12 Thread Lydia Pintscher

2013/2/11 Lydia Pintscher :
> Heya :)
>
> We tried to deploy phase 1 on enwp today but ran into issues. We'll
> have to reschedule. Currently it looks like we'll do this on
> Wednesday.
> Sorry folks.

We'll do another attempt later today (probably around 17:00 UTC).


Cheers
Lydia

-- 
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications for Wikidata

Wikimedia Deutschland e.V.
Obentrautstr. 72
10963 Berlin
www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Fwd: [Gerrit] API PageSet allows generator for non-query modules - change (mediawiki/core[master])

2013-02-12 Thread Antoine Musso

Le 06/02/13 23:48, Tyler Romeo wrote:

> The only mistake it can lead to is if there's a typo in a variable name,
> but in cases like this:

There are a few more possible such as 0 or "0" being considered empty.
And as you said, that hide the fact a variable is not defined, that is
sometime useful, lot of the time hiding an error.

>> If I wanted to check an array is empty I would probably:
>>
>>  count( $array ) === 0
> 
>  count() requires determining the size of the array, which is significantly
> slower than any of the solutions.

Your assumption is probably based on the meaning of the word "count" but
does not reflect the PHP implementation for an array. That is actually a
hashtable which keep track of the number of elements it contains,
counting is just about returning that value.

In ext/standard/array.c:

// The count() function definition:
PHP_FUNCTION(count)
...
 case IS_ARRAY:
   RETURN_LONG (php_count_recursive (array, mode TSRMLS_CC));

// Counting the element in an array:
static int php_count_recursive(zval *array, long mode TSRMLS_DC)
  ..
  cnt = zend_hash_num_elements(Z_ARRVAL_P(array));

That zend_hash_num_elements is in Zend/zend_hash.c so small I am pasting
it fully:

ZEND_API int zend_hash_num_elements(const HashTable *ht) {
IS_CONSISTENT(ht);
return ht->nNumOfElements;
}

As we can see, the array is ultimately a HashTable which has a property
to give out the number of elements in it.  It is incremented whenever
one add an object to the HashTable :-]

-- 
Antoine "hashar" Musso

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Stable PHP API for MediaWiki ?

2013-02-12 Thread Maria Miteva

Hi everyone,

I guess it is a little difficult for me to describe what I mean since I am
just rephrasing what I've heard from others. I am still waiting for some
more specific examples. However, I think most people are facing the kind of
 problems which Daniel has so well described in his post to the mailing
list.

Maybe this quotation will help clarify things.

Mostly I want core developers to think about MediaWiki as framework with
programming interfaces for extension developers. All the changes in those
interfaces have to be calm, with slow deprecation. A role model for that is
Python compiler.
(
http://www.mediawiki.org/wiki/Talk:Third-party_MediaWiki_users_discussion#Features_Wish_List_22689
 )

I understand from your comments that keeping things stable and preserving
compatibiliy HAS been a priority for core developers at least since
Daniel's email. Is this really the case? If this is the case, it makes me
wonder why I hear some complaints about it. Is it maybe that documentation
is not clear on what will be stable and can be used and what should not be
used? Or is it a matter of educating extension developers how to find such
information?

On a brighter note, I heard that the LTS version 1.19 was the best thing
that happened since sliced bread :)

Mariya

On Tue, Feb 12, 2013 at 10:03 AM, Antoine Musso  wrote:

> Le 11/02/13 19:58, vita...@yourcmc.ru a écrit :
> >> 1) removal of global $action
> >> 2) removal of Xml::hidden()
> >> 3) broken Output::add() (had to migrate to resource loader)
> >> 4) various parser tag bugs
> >> 5) removal of MessageCache::addMessage()
> >> 6) removal of ts_makeSortable() (javascript)
> >> 7) brokage of WikiEditor adaptation
> >> 8) MediaWiki:common.js no more loading by default (security)
> >> 9) addHandler() javascript broken in IE8
> >
> > Most of these were deprecations, am I correct?
> >
>
> I guess so.  Probably methods we simply removed instead of deprecating
> them like we are doing nowadays.
>
> --
> Antoine "hashar" Musso
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Stable PHP API for MediaWiki ?

2013-02-12 Thread Mariya Nedelcheva Miteva

By the way, Daniel, have you had similar problems with your next upgrades?
Maybe things have indeed improved since your post about 1.18


Mariya

On Tue, Feb 12, 2013 at 3:14 PM, Maria Miteva wrote:

> Hi everyone,
>
> I guess it is a little difficult for me to describe what I mean since I am
> just rephrasing what I've heard from others. I am still waiting for some
> more specific examples. However, I think most people are facing the kind of
>  problems which Daniel has so well described in his post to the mailing
> list.
>
> Maybe this quotation will help clarify things.
>
> Mostly I want core developers to think about MediaWiki as framework with
> programming interfaces for extension developers. All the changes in those
> interfaces have to be calm, with slow deprecation. A role model for that is
> Python compiler.
> (
> http://www.mediawiki.org/wiki/Talk:Third-party_MediaWiki_users_discussion#Features_Wish_List_22689
>  )
>
> I understand from your comments that keeping things stable and preserving
> compatibiliy HAS been a priority for core developers at least since
> Daniel's email. Is this really the case? If this is the case, it makes me
> wonder why I hear some complaints about it. Is it maybe that documentation
> is not clear on what will be stable and can be used and what should not be
> used? Or is it a matter of educating extension developers how to find such
> information?
>
> On a brighter note, I heard that the LTS version 1.19 was the best thing
> that happened since sliced bread :)
>
> Mariya
>
>
> On Tue, Feb 12, 2013 at 10:03 AM, Antoine Musso wrote:
>
>> Le 11/02/13 19:58, vita...@yourcmc.ru a écrit :
>> >> 1) removal of global $action
>> >> 2) removal of Xml::hidden()
>> >> 3) broken Output::add() (had to migrate to resource loader)
>> >> 4) various parser tag bugs
>> >> 5) removal of MessageCache::addMessage()
>> >> 6) removal of ts_makeSortable() (javascript)
>> >> 7) brokage of WikiEditor adaptation
>> >> 8) MediaWiki:common.js no more loading by default (security)
>> >> 9) addHandler() javascript broken in IE8
>> >
>> > Most of these were deprecations, am I correct?
>> >
>>
>> I guess so.  Probably methods we simply removed instead of deprecating
>> them like we are doing nowadays.
>>
>> --
>> Antoine "hashar" Musso
>>
>>
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Stable PHP API for MediaWiki ?

2013-02-12 Thread vitalif

I understand from your comments that keeping things stable and 
preserving

compatibiliy HAS been a priority for core developers at least since
Daniel's email. Is this really the case? If this is the case, it 
makes me

wonder why I hear some complaints about it.


Mariya, but did you hear that many complaints? :-)


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Stable PHP API for MediaWiki ?

2013-02-12 Thread Daniel Barrett

We had quite a bit of difficulty moving from 1.18 to 1.20 because of mysterious 
JavaScript timing issues in WikiEditor.
http://www.mediawiki.org/wiki/Talk:MediaWiki_vendors#WikiEditor_toolbars.2C_JavaScript_dependencies.2C_and_asynchronous_behavior_22765

On the PHP side, some protected variables in a class (I think UserMailer) got 
changed to private, which broke some extensions that subclassed it.  That kind 
of change should be strongly discouraged, or accompanied by some new functions 
that access the now-private member.

DanB

From: mnm...@nyu.edu [mailto:mnm...@nyu.edu] On Behalf Of Mariya Nedelcheva 
Miteva
Sent: Tuesday, February 12, 2013 9:23 AM
To: Daniel Barrett; Wikimedia developers
Subject: Re: [Wikitech-l] Stable PHP API for MediaWiki ?

By the way, Daniel, have you had similar problems with your next upgrades? 
Maybe things have indeed improved since your post about 1.18

Mariya
On Tue, Feb 12, 2013 at 3:14 PM, Maria Miteva 
mailto:mariya.mit...@gmail.com>> wrote:
Hi everyone,

I guess it is a little difficult for me to describe what I mean since I am just 
rephrasing what I've heard from others. I am still waiting for some more 
specific examples. However, I think most people are facing the kind of  
problems which Daniel has so well described in his post to the mailing list.

Maybe this quotation will help clarify things.

Mostly I want core developers to think about MediaWiki as framework with 
programming interfaces for extension developers. All the changes in those 
interfaces have to be calm, with slow deprecation. A role model for that is 
Python compiler.
( 
http://www.mediawiki.org/wiki/Talk:Third-party_MediaWiki_users_discussion#Features_Wish_List_22689
 )

I understand from your comments that keeping things stable and preserving 
compatibiliy HAS been a priority for core developers at least since Daniel's 
email. Is this really the case? If this is the case, it makes me wonder why I 
hear some complaints about it. Is it maybe that documentation is not clear on 
what will be stable and can be used and what should not be used? Or is it a 
matter of educating extension developers how to find such information?

On a brighter note, I heard that the LTS version 1.19 was the best thing that 
happened since sliced bread :)

Mariya

On Tue, Feb 12, 2013 at 10:03 AM, Antoine Musso 
mailto:hashar+...@free.fr>> wrote:
Le 11/02/13 19:58, vita...@yourcmc.ru a écrit :
>> 1) removal of global $action
>> 2) removal of Xml::hidden()
>> 3) broken Output::add() (had to migrate to resource loader)
>> 4) various parser tag bugs
>> 5) removal of MessageCache::addMessage()
>> 6) removal of ts_makeSortable() (javascript)
>> 7) brokage of WikiEditor adaptation
>> 8) MediaWiki:common.js no more loading by default (security)
>> 9) addHandler() javascript broken in IE8
>
> Most of these were deprecations, am I correct?
>
I guess so.  Probably methods we simply removed instead of deprecating
them like we are doing nowadays.

--
Antoine "hashar" Musso

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-12 Thread Daniel Barrett

I wished for:
>> 1. A desire for a department to have "their own space" on the wiki.

S Page asked:
>I assume you looked at enabling subpages in the main namespace?[1]
>That way Human Resources/Payroll/Show_me_the_money gets a nice breadcrumb up 
>to Payroll
>and Human Resources landing pages.

Interesting idea, but I think subpages also bring penalties that are pretty 
significant. I discuss these in my book 
(http://shop.oreilly.com/product/9780596519681.do):

- Linking to subpages is quite cumbersome. The names get very long, and you 
wind up doing lots of [[foo/bar/blat/a/b/c | alt text]] links which add 
complexity to editing the page.  We find that this discourages people from 
adding links to pages.

- When you enable subpages for a large community, they start using them instead 
of categories.  In other words, users now have a choice between putting 
"Benefits" in the Human Resources category, or creating "Human 
Resources/Benefits." As a result, some Benefits pages end up in the Benefits 
category while others end up as subpages, making the "Benefits" category 
incomplete.  An incomplete category can be worse than no category at all, 
because people look in it, don't find what they want, and assume it doesn't 
exist. Also, I'd rather have a category with 200 members than a page with 200 
subpages.

- MediaWiki's UI does not indicate whether a page has subpages. There are 
extensions to solve this, but I haven't found one that integrates seamlessly 
into the user's daily experience the way (say) category links do.

For our large wiki, we decided that subpages in the main namespace are not 
worth these disadvantages.

Hope this was interesting,
DanB

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Bugzilla use by development teams

2013-02-12 Thread Andre Klapper

Hi,

recently I've collected info on the usage of Bugzilla by Wikimedia's
development teams, listing each team's 
* Bugzilla components (projects), 
* bug tracking and development planning tools, 
* criticism and wishes about Bugzilla specifically, 
* use of Bugzilla's "Priority" field.

There are still many blank fields and it's work in progress.
I'm sharing it here as it might be useful for others, plus you are of
course welcome to correct or add any data:

https://www.mediawiki.org/wiki/Bug_management/Development_teams_usage

andre
-- 
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/


___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Font at dv.wikipedia and dv.wiktionary

2013-02-12 Thread Gerard Meijssen

Hoi,
I have been looking at the font.. The one thing that is important and I
cannot find is an indication of the license. When the font is available
under a free license, it will be relatively easy to get it and possibly
other fonts as well included as a web font in MediaWiki.
Thanks,
 GerardM


On 12 February 2013 09:56, oәuɐႡɔsʇnәp nɐႡsn  wrote:

> Hello. The fonts at Dhivehi Wikipedia and Wiktionary are not webfonts. If
> possible could the fonts be changed to Faruma which can be downloaded from
> here:
> http://bazaar.launchpad.net/~mvishah/ttf-dhivehi-fonts/trunk/view/head:/ttf-thaana-fonts/faruma.ttf.
>  Originally this issue was raised at
> http://dv.wikipedia.org/wiki/User_talk:Glacious#Fonts by User:Vituzzu. I
> have tried
> http://www.mediawiki.org/wiki/Extension:WebFonts#Preparing_webfonts but
> to no result. Can someone help me regarding this matter.
> Links: dv.wikipedia.orgdv.wiktionary.org
> MediaWiki - 1.21wmf8 (17a7840)PHP - 5.3.10-1ubuntu3.4+wmf1
> (apache2handler)MySQL - 5.1.53-wm-log
> I have posted this question at the MediaWiki support desk here:
> http://www.mediawiki.org/wiki/Thread:Project:Support_desk/Font_at_dv.wikipedia_and_dv.wiktionaryand
>  User:MarkAHershberger directed me to
> https://bugzilla.wikimedia.org/show_bug.cgi?id=42812 but no one is
> responding in there. So he told me to mail to this list.
> Regards,Ushau
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Corporate needs are different (RE: How can we help Corporations use MW?)

2013-02-12 Thread Mark A. Hershberger

On 02/11/2013 11:25 AM, Daniel Barrett wrote:
> Imagine if Wikipedia had a separate wiki for every city in the world. The 
> same problem would result.

I find it is easier to imagine what would happen if each language had a
separate Wikipedia.  We would end up with slightly different facts
maintained on each wiki.

Imagine the chaos!

;)

-- 
http://hexmode.com/

There is no path to peace. Peace is the path.
   -- Mahatma Gandhi, "Non-Violence in Peace and War"

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Font at dv.wikipedia and dv.wiktionary

2013-02-12 Thread Paul Selitskas

These fonts seem to be packaged in a .deb-pack.
http://bazaar.launchpad.net/~mvishah/ttf-dhivehi-fonts/trunk/view/head:/debian/copyright


On Tue, Feb 12, 2013 at 7:30 PM, Gerard Meijssen
wrote:

> Hoi,
> I have been looking at the font.. The one thing that is important and I
> cannot find is an indication of the license. When the font is available
> under a free license, it will be relatively easy to get it and possibly
> other fonts as well included as a web font in MediaWiki.
> Thanks,
>  GerardM
>
>
> On 12 February 2013 09:56, oәuɐႡɔsʇnәp nɐႡsn  wrote:
>
> > Hello. The fonts at Dhivehi Wikipedia and Wiktionary are not webfonts. If
> > possible could the fonts be changed to Faruma which can be downloaded
> from
> > here:
> >
> http://bazaar.launchpad.net/~mvishah/ttf-dhivehi-fonts/trunk/view/head:/ttf-thaana-fonts/faruma.ttf.
> Originally this issue was raised at
> > http://dv.wikipedia.org/wiki/User_talk:Glacious#Fonts by User:Vituzzu. I
> > have tried
> > http://www.mediawiki.org/wiki/Extension:WebFonts#Preparing_webfonts but
> > to no result. Can someone help me regarding this matter.
> > Links: dv.wikipedia.orgdv.wiktionary.org
> > MediaWiki - 1.21wmf8 (17a7840)PHP - 5.3.10-1ubuntu3.4+wmf1
> > (apache2handler)MySQL - 5.1.53-wm-log
> > I have posted this question at the MediaWiki support desk here:
> >
> http://www.mediawiki.org/wiki/Thread:Project:Support_desk/Font_at_dv.wikipedia_and_dv.wiktionaryandUser:MarkAHershberger
>  directed me to
> > https://bugzilla.wikimedia.org/show_bug.cgi?id=42812 but no one is
> > responding in there. So he told me to mail to this list.
> > Regards,Ushau
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
З павагай,
Павел Селіцкас/Pavel Selitskas
Wizardist @ Wikimedia projects
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Font at dv.wikipedia and dv.wiktionary

2013-02-12 Thread Mark A. Hershberger

On 02/12/2013 03:56 AM, oәuɐႡɔsʇnәp nɐႡsn wrote:
> Hello. The fonts at Dhivehi Wikipedia and Wiktionary are not webfonts. If 
> possible could the fonts be changed
> to Faruma which can be downloaded from here:
>
http://bazaar.launchpad.net/~mvishah/ttf-dhivehi-fonts/trunk/view/head:/ttf-thaana-fonts/faruma.ttf

The copyright for that package is GPL (see
https://bazaar.launchpad.net/~mvishah/ttf-dhivehi-fonts/trunk/view/head:/debian/copyright),
which we could use.

However, it isn't clear that the font itself is under the GPL. The
copyright file says "downloaded from http://moss.org.mv"; but
moss.org.mv doesn't appear to be registered currently so there is no DNS
domain.

IANAL, but I think we need to show proper provenance for the fonts
before we can use it and right now, it looks like I'm hitting a dead end.

-- 
http://hexmode.com/

There is no path to peace. Peace is the path.
   -- Mahatma Gandhi, "Non-Violence in Peace and War"

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] RFC: Introducing two new HTTP headers to track mobile pageviews

2013-02-12 Thread Diederik van Liere

> It does still seem to me that the data to determine secondary api requests
> should already be present in the existing log line. If the value of the
> page param in an action=mobileview api request matches the page in the
> referrer (perhaps with normalization), it's a secondary request as per case
> 1 below.  Otherwise, it's a pageview as per case 2.  Difficult or expensive
> to reconcile?  Not when you're doing distributed log analysis via hadoop.
>
So I did look into this prior to writing the RFC and the issue is that a
lot of API referrers don't contain the querystring. I don't know what
triggers this so if we can fix this then we can definitely derive the
secondary pageview request from the referrer field.
D



> On Mon, Feb 11, 2013 at 7:11 PM, Arthur Richards  >wrote:
>
> > Thanks, Jon. To try and clarify a bit more about the API requests... they
> > are not made on a per-section basis. As I mentioned earlier, there are
> two
> > cases in which article content gets loaded by the API:
> >
> > 1) Going directly to a page (eg clicking a link from a Google search)
> will
> > result in the backend serving a page with ONLY summary section content
> and
> > section headers. The rest of the page is lazily loaded via API request
> once
> > the JS for the page gets loaded. The idea is to increase responsiveness
> by
> > reducing the delay for an article to load (further details in the article
> > Jon previously linked to). The API request looks like:
> >
> >
> http://en.m.wikipedia.org/w/api.php?format=json&action=mobileview&page=Liverpool+F.C.+in+European+football&variant=en&redirects=yes&prop=sections%7Ctext&noheadings=yes§ionprop=level%7Cline%7Canchor§ions=all
> >
> > 2) Loading an article entirely via Javascript - like when a link is
> clicked
> > in an article to another article, or an article is loaded via search.
> This
> > will make ONE call to the API to load article content. API request looks
> > like:
> >
> >
> http://en.m.wikipedia.org/w/api.php?format=json&action=mobileview&page=Liverpool+F.C.+in+European+football&variant=en&redirects=yes&prop=sections%7Ctext&noheadings=yes§ionprop=level%7Cline%7Canchor§ions=all
> >
> > These API requests are identical, but only #2 should be counted as a
> > 'pageview' - #1 is a secondary API request and should not be counted as a
> > 'pageview'. You could make the argument that we just count all of these
> API
> > requests as pageviews, but there are cases when we can't load article
> > content from the API (like devices that do not support JS), so we need to
> > be able to count the traditional page request as a pageview - thus we
> need
> > a way to differentiate the types of API requests being made when they
> > otherwise share the same URL.
> >
> >
> >
> > On Mon, Feb 11, 2013 at 6:42 PM, Jon Robson  wrote:
> >
> > > I'm a bit worried that now we are asking why pages are lazy loaded
> > > rather than focusing on the fact that they currently __are doing
> > > this___ and how we can log these (if we want to discuss this further
> > > let's start another thread as I'm getting extremely confused doing so
> > > on this one).
> > >
> > > Lazy loading sections
> > > 
> > > For motivation behind moving MobileFrontend into the direction of lazy
> > > loading section content and subsequent pages can be found here [1], I
> > > just gave it a refresh as it was a little out of date.
> > >
> > > In summary the reason is to
> > > 1) make the app feel more responsive by simply loading content rather
> > > than reloading the entire interface
> > > 2) reducing the payload sent to a device.
> > >
> > > Session Tracking
> > > 
> > >
> > > Going back to the discussion of tracking mobile page views, it sounds
> > > like a header stating whether a page is being viewed in alpha, beta or
> > > stable works fine for standard page views.
> > >
> > > As for the situations where an entire page is loaded via the api it
> > > makes no difference to us to whether we
> > > 1) send the same header (set via javascript) or
> > > 2) add a query string parameter.
> > >
> > > The only advantage I can see of using a header is that an initial page
> > > load of the article San Francisco currently uses the same api url as a
> > > page load of the article San Francisco via javascript (e.g. I click a
> > > link to 'San Francisco' on the California article).
> > >
> > > In this new method they would use different urls (as the data sent is
> > > different). I'm not sure how that would effect caching.
> > >
> > > Let us know which method is preferred. From my perspective
> > > implementation of either is easy.
> > >
> > > [1] http://www.mediawiki.org/wiki/MobileFrontend/Dynamic_Sections
> > >
> > > On Mon, Feb 11, 2013 at 12:50 PM, Asher Feldman <
> afeld...@wikimedia.org>
> > > wrote:
> > > > Max - good answers re: caching concerns.  That leaves studying if the
> > > bytes
> > > > transferred on average mobile article view increases or decreases
> with
> > > lazy
> > >

Re: [Wikitech-l] [Wmfall] Announcement: Ed Sanders joins Wikimedia as Visual Editor Software Engineer

2013-02-12 Thread Sumana Harihareswara

On 02/11/2013 08:58 PM, Terry Chay wrote:
> Everyone,
> 
> I'm delighted to announce that Ed Sanders has joined the VisualEditor[0] team 
> as a software engineer from today. He will be focussed on the data structures 
> and APIs inside the VisualEditor, and in particular its "data model" 
> component. Ed will be working remotely from the UK.
> 
> Ed has worked as a Web front-end software engineer for several years, most 
> recently working for TripAdvisor. He received his MA in Computer Science from 
> Clare College at the University of Cambridge.
> 
> Ed  is a long-term contributor to Commons and the English Wikipedia, where he 
> has been a sysop since 2004.[1] In his spare time, Ed enjoys photography, 
> watching his local football team (real football, not handegg), Arsenal,[2] 
> and sometimes doing both at the same time.
> 
> He'll be in the SF office for the next few weeks so be sure to stop by and 
> say hi!
> 
> Please join me in welcoming Ed!
> 
> terry
> [0] - https://www.mediawiki.org/wiki/VisualEditor
> [1] - https://commons.wikimedia.org/wiki/User:Ed_g2s
> [2] - https://en.wikipedia.org/wiki/Arsenal

Welcome, Ed!  Wow, sysop for the past eleven years!  You have a lot of
engineering expertise and community experience, and I am very grateful
that WMF is getting the benefit of that.  Thanks for joining us.

-- 
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Announcement: Ed Sanders joins Wikimedia as Visual Editor Software Engineer

2013-02-12 Thread Sumana Harihareswara

On 02/12/2013 12:23 PM, Sumana Harihareswara wrote:
> On 02/11/2013 08:58 PM, Terry Chay wrote:
>> Everyone,
>>
>> I'm delighted to announce that Ed Sanders has joined the VisualEditor[0] 
>> team as a software engineer from today. He will be focussed on the data 
>> structures and APIs inside the VisualEditor, and in particular its "data 
>> model" component. Ed will be working remotely from the UK.
>>
>> Ed has worked as a Web front-end software engineer for several years, most 
>> recently working for TripAdvisor. He received his MA in Computer Science 
>> from Clare College at the University of Cambridge.
>>
>> Ed  is a long-term contributor to Commons and the English Wikipedia, where 
>> he has been a sysop since 2004.[1] In his spare time, Ed enjoys photography, 
>> watching his local football team (real football, not handegg), Arsenal,[2] 
>> and sometimes doing both at the same time.
>>
>> He'll be in the SF office for the next few weeks so be sure to stop by and 
>> say hi!
>>
>> Please join me in welcoming Ed!
>>
>> terry
>> [0] - https://www.mediawiki.org/wiki/VisualEditor
>> [1] - https://commons.wikimedia.org/wiki/User:Ed_g2s
>> [2] - https://en.wikipedia.org/wiki/Arsenal
> 
> Welcome, Ed!  Wow, sysop for the past eleven years!  You have a lot of
> engineering expertise and community experience, and I am very grateful
> that WMF is getting the benefit of that.  Thanks for joining us.

s/11/9/

*Sumana slinks off quietly*

-- 
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] RFC: Introducing two new HTTP headers to track mobile pageviews

2013-02-12 Thread Asher Feldman

On Tuesday, February 12, 2013, Diederik van Liere wrote:

> > It does still seem to me that the data to determine secondary api
> requests
> > should already be present in the existing log line. If the value of the
> > page param in an action=mobileview api request matches the page in the
> > referrer (perhaps with normalization), it's a secondary request as per
> case
> > 1 below.  Otherwise, it's a pageview as per case 2.  Difficult or
> expensive
> > to reconcile?  Not when you're doing distributed log analysis via hadoop.
> >
> So I did look into this prior to writing the RFC and the issue is that a
> lot of API referrers don't contain the querystring. I don't know what
> triggers this so if we can fix this then we can definitely derive the
> secondary pageview request from the referrer field.
> D


If you can point me to some examples, I'll see if I can find any insights
into the behavior.


>
> > On Mon, Feb 11, 2013 at 7:11 PM, Arthur Richards <
> aricha...@wikimedia.org
> > >wrote:
> >
> > > Thanks, Jon. To try and clarify a bit more about the API requests...
> they
> > > are not made on a per-section basis. As I mentioned earlier, there are
> > two
> > > cases in which article content gets loaded by the API:
> > >
> > > 1) Going directly to a page (eg clicking a link from a Google search)
> > will
> > > result in the backend serving a page with ONLY summary section content
> > and
> > > section headers. The rest of the page is lazily loaded via API request
> > once
> > > the JS for the page gets loaded. The idea is to increase responsiveness
> > by
> > > reducing the delay for an article to load (further details in the
> article
> > > Jon previously linked to). The API request looks like:
> > >
> > >
> >
> http://en.m.wikipedia.org/w/api.php?format=json&action=mobileview&page=Liverpool+F.C.+in+European+football&variant=en&redirects=yes&prop=sections%7Ctext&noheadings=yes§ionprop=level%7Cline%7Canchor§ions=all
> > >
> > > 2) Loading an article entirely via Javascript - like when a link is
> > clicked
> > > in an article to another article, or an article is loaded via search.
> > This
> > > will make ONE call to the API to load article content. API request
> looks
> > > like:
> > >
> > >
> >
> http://en.m.wikipedia.org/w/api.php?format=json&action=mobileview&page=Liverpool+F.C.+in+European+football&variant=en&redirects=yes&prop=sections%7Ctext&noheadings=yes§ionprop=level%7Cline%7Canchor§ions=all
> > >
> > > These API requests are identical, but only #2 should be counted as a
> > > 'pageview' - #1 is a secondary API request and should not be counted
> as a
> > > 'pageview'. You could make the argument that we just count all of these
> > API
> > > requests as pageviews, but there are cases when we can't load article
> > > content from the API (like devices that do not support JS), so we need
> to
> > > be able to count the traditional page request as a pageview - thus we
> > need
> > > a way to differentiate the types of API requests being made when they
> > > otherwise share the same URL.
> > >
> > >
> > >
> > > On Mon, Feb 11, 2013 at 6:42 PM, Jon Robson 
> wrote:
> > >
> > > > I'm a bit worried that now we are asking why pages are lazy loaded
> > > > rather than focusing on the fact that they currently __are doing
> > > > this___ and how we can log these (if we want to discuss this further
> > > > let's start another thread as I'm getting extremely confused doing so
> > > > on this one).
> > > >
> > > > Lazy loading sections
> > > > 
> > > > For motivation behind moving MobileFrontend into the direction of
> lazy
> > > > loading section content and subsequent pages can be found here [1], I
> > > > just gave it a refresh as it was a little out of date.
> > > >
> > > > In summary the reason is to
> > > > 1) make the app feel more responsive by simply loading content rather
> > > > than reloading the entire interface
> > > > 2) reducing the payload sent to a device.
> > > >
> > > > Session Tracking
> > > > 
> > > >
> > > > Going back to the discussion of tracking mobile page views, it sounds
> > > > like a header stating whether a page is being viewed in alpha, beta
> or
> > > > stable works fine for standard page views.
> > > >
> > > > As for the situations where an entire page is loaded via the api it
> > > > makes no dif
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Announcement: Ed Sanders joins Wikimedia as Visual Editor Software Engineer

2013-02-12 Thread bawolff

>
> s/11/9/
>
> *Sumana slinks off quietly*
>
> --
> Sumana Harihareswara
> Engineering Community Manager
> Wikimedia Foundation

9 is still an extremely impressive number. When did sysops get
introduced? I have a feeling that 11 years ago there was no such
thing.

Welcome Ed!

--bawolff

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Wmfall] Announcement: Ed Sanders joins Wikimedia as Visual Editor Software Engineer

2013-02-12 Thread James Forrester

On 12 February 2013 09:59, bawolff  wrote:
> 9 is still an extremely impressive number. When did sysops get
> introduced? I have a feeling that 11 years ago there was no such
> thing.

I believe that our first sysops (i.e. accounts with some special
status) were in 2002; before that, there was the shared "admin"
password for which UseMod prompted you if you wanted to delete
something, which was shared with some trusted users.

J.
--
James D. Forrester
jdforres...@gmail.com
[[Wikipedia:User:Jdforrester|James F.]] (speaking purely in a personal capacity)

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit 2.6 - coming to a server near you

2013-02-12 Thread Matthew Walker

I am liking the new UI features. However -- I notice that I seem to have
lost +2 rights to mediawiki/core. Are we rolling back the policy that all
foundation developers have +2?

~Matt Walker

On Mon, Feb 11, 2013 at 6:33 PM, Chad  wrote:

> On Mon, Feb 11, 2013 at 6:49 PM, Chad  wrote:
> > On Fri, Feb 8, 2013 at 8:52 AM, Chad  wrote:
> >> Rest assured--we will still be getting the latest and greatest. And
> we're still
> >> on target for late Monday/early Tuesday.
> >>
> >
> > Friendly reminder that Gerrit will be coming down in about an hour
> > for the upgrade. During the upgrade, you may be able to hit Gerrit
> > intermittently as it'll restart several times. Once the dust has
> > settled, I'll be sure to let everyone know.
> >
>
> Took a few minutes longer than expected, but we're back up and
> everything's live. We had to deploy a newer version to grab one
> last fix we spotted during the upgrade. Our deployed version is
> now 2.5.1-1266-gcc231e1.
>
> There might be a few problems left over with the IRC notifications,
> I'll tackle those tomorrow (making sure replication is working properly
> now). If you spot any other problems, please let me know.
>
> -Chad
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit 2.6 - coming to a server near you

2013-02-12 Thread Chad

On Tue, Feb 12, 2013 at 1:45 PM, Matthew Walker  wrote:
> I am liking the new UI features. However -- I notice that I seem to have
> lost +2 rights to mediawiki/core. Are we rolling back the policy that all
> foundation developers have +2?
>

No, this should not have changed...

-Chad

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit 2.6 - coming to a server near you

2013-02-12 Thread Bartosz Dziewoński


Are you logged in? Everyone got logged out apparently, and this bit me at 
first, too.

--
Matma Rex

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit 2.6 - coming to a server near you

2013-02-12 Thread Matthew Walker

Yep. Logged in as mwal...@wikimedia.org. It's odd because I still have +2
on the fundraising repos. Maybe the ACL computation changed and I'm not in
some group that I should have been in?

~Matt Walker

On Tue, Feb 12, 2013 at 10:54 AM, Bartosz Dziewoński wrote:

> Are you logged in? Everyone got logged out apparently, and this bit me at
> first, too.
>
> --
> Matma Rex
>
>
> __**_
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] deployment of the first phase of Wikidata on enwp

2013-02-12 Thread Lydia Pintscher

Hey,

There were unfortunately too many other issues unrelated to Wikidata
so we also had to call off this one. Sorry.


Cheers
Lydia

--
Lydia Pintscher - http://about.me/lydia.pintscher
Community Communications for Wikidata

Wikimedia Deutschland e.V.
Obentrautstr. 72
10963 Berlin
www.wikimedia.de

Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg
unter der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das
Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit 2.6 - coming to a server near you

2013-02-12 Thread Merlijn van Deen

Hi Chad,

On 12 February 2013 03:33, Chad  wrote:
> Took a few minutes longer than expected, but we're back up and
> everything's live. We had to deploy a newer version to grab one
> last fix we spotted during the upgrade. Our deployed version is
> now 2.5.1-1266-gcc231e1.

Thanks for performing the upgrade!

I'm not sure if anything but the reviewer bot (and the UI) uses the
API, but it has been *moved* from
https://gerrit.wikimedia.org/r/gerrit/rpc/ChangeDetailService to
https://gerrit.wikimedia.org/r/gerrit_ui/rpc/ChangeDetailService . It
will return an Internal Server Error when the original URL is accessed
(with POST data, from the browser it's 404).

This might be related to the errors seen by Matt and Roan: old
javascript code trying to access the old URL.

Merlijn

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Font at dv.wikipedia and dv.wiktionary

2013-02-12 Thread Ryan Kaldari

Nevermind, I didn't read the initial post of this thread (which had been 
cut out). It sounds like you're looking for a font that can be 
distributed with Mediawiki as a webfont, in which case it does need to 
be free license.


Ryan Kaldari

On 2/12/13 8:49 AM, Mark A. Hershberger wrote:

On 02/12/2013 03:56 AM, oәuɐႡɔsʇnәp nɐႡsn wrote:

Hello. The fonts at Dhivehi Wikipedia and Wiktionary are not webfonts. If 
possible could the fonts be changed
to Faruma which can be downloaded from here:


http://bazaar.launchpad.net/~mvishah/ttf-dhivehi-fonts/trunk/view/head:/ttf-thaana-fonts/faruma.ttf

The copyright for that package is GPL (see
https://bazaar.launchpad.net/~mvishah/ttf-dhivehi-fonts/trunk/view/head:/debian/copyright),
which we could use.

However, it isn't clear that the font itself is under the GPL. The
copyright file says "downloaded from http://moss.org.mv"; but
moss.org.mv doesn't appear to be registered currently so there is no DNS
domain.

IANAL, but I think we need to show proper provenance for the fonts
before we can use it and right now, it looks like I'm hitting a dead end.





___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit 2.6 - coming to a server near you

2013-02-12 Thread Chad

On Tue, Feb 12, 2013 at 4:18 PM, Merlijn van Deen  wrote:
> Hi Chad,
>
> On 12 February 2013 03:33, Chad  wrote:
>> Took a few minutes longer than expected, but we're back up and
>> everything's live. We had to deploy a newer version to grab one
>> last fix we spotted during the upgrade. Our deployed version is
>> now 2.5.1-1266-gcc231e1.
>
> Thanks for performing the upgrade!
>
> I'm not sure if anything but the reviewer bot (and the UI) uses the
> API, but it has been *moved* from
> https://gerrit.wikimedia.org/r/gerrit/rpc/ChangeDetailService to
> https://gerrit.wikimedia.org/r/gerrit_ui/rpc/ChangeDetailService . It
> will return an Internal Server Error when the original URL is accessed
> (with POST data, from the browser it's 404).
>
> This might be related to the errors seen by Matt and Roan: old
> javascript code trying to access the old URL.
>

As we just discussed on IRC, the JSON-RPC interface has largely
been removed and replaced by the RESTful APIs which are meant
for public consumption and are going to be much more stable. For
anyone who's interested in developing things against the API, there
are docs: https://gerrit.wikimedia.org/r/Documentation/rest-api.html

The problem Roan and others were having with adding reviewers
was unrelated, and should be fixed now.

-Chad

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Font at dv.wikipedia and dv.wiktionary

2013-02-12 Thread Ryan Kaldari

We don't have to limit ourselves to free license fonts for what we use 
on our own servers. We only have to limit ourselves to free license 
fonts for what we distribute with our software. Of course, we should 
always try to support free license fonts when they are available, but 
there is no reason for us to artificially limit ourselves to free fonts 
for our own projects (assuming the licensing fees are reasonable).


Ryan Kaldari

On 2/12/13 8:49 AM, Mark A. Hershberger wrote:

On 02/12/2013 03:56 AM, oәuɐႡɔsʇnәp nɐႡsn wrote:

Hello. The fonts at Dhivehi Wikipedia and Wiktionary are not webfonts. If 
possible could the fonts be changed
to Faruma which can be downloaded from here:


http://bazaar.launchpad.net/~mvishah/ttf-dhivehi-fonts/trunk/view/head:/ttf-thaana-fonts/faruma.ttf

The copyright for that package is GPL (see
https://bazaar.launchpad.net/~mvishah/ttf-dhivehi-fonts/trunk/view/head:/debian/copyright),
which we could use.

However, it isn't clear that the font itself is under the GPL. The
copyright file says "downloaded from http://moss.org.mv"; but
moss.org.mv doesn't appear to be registered currently so there is no DNS
domain.

IANAL, but I think we need to show proper provenance for the fonts
before we can use it and right now, it looks like I'm hitting a dead end.





___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit 2.6 - coming to a server near you

2013-02-12 Thread Tyler Romeo

Some other new features I've noticed that haven't been listed:
* Showing who has the ability to vote in each category (easily identify
project owners).
* Switch patchsets while in diff view.
* Changes show if they need to be rebased.

*--*
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com


On Tue, Feb 12, 2013 at 4:18 PM, Merlijn van Deen wrote:

> Hi Chad,
>
> On 12 February 2013 03:33, Chad  wrote:
> > Took a few minutes longer than expected, but we're back up and
> > everything's live. We had to deploy a newer version to grab one
> > last fix we spotted during the upgrade. Our deployed version is
> > now 2.5.1-1266-gcc231e1.
>
> Thanks for performing the upgrade!
>
> I'm not sure if anything but the reviewer bot (and the UI) uses the
> API, but it has been *moved* from
> https://gerrit.wikimedia.org/r/gerrit/rpc/ChangeDetailService to
> https://gerrit.wikimedia.org/r/gerrit_ui/rpc/ChangeDetailService . It
> will return an Internal Server Error when the original URL is accessed
> (with POST data, from the browser it's 404).
>
> This might be related to the errors seen by Matt and Roan: old
> javascript code trying to access the old URL.
>
> Merlijn
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Belated welcome to Christian Aistleitner

2013-02-12 Thread Rob Lanphier

Hi everyone,

I'd like to give an extremely belated welcome to Christian
Aistleitner. Christian is working as a contractor for Wikimedia
Foundation specializing in Gerrit work, who started working with us in
mid-January.  Christian was very helpful in getting the Gerrit 2.6pre
upgrade to happen, and is working on the backlog of features that we'd
like for Gerrit (e.g. project renames, project deletions, better
Bugzilla integration).  He'll be working with us through the end of
April.

Welcome Christian!

Rob

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Belated welcome to Christian Aistleitner

2013-02-12 Thread Sumana Harihareswara

On 02/12/2013 05:38 PM, Rob Lanphier wrote:
> Hi everyone,
> 
> I'd like to give an extremely belated welcome to Christian
> Aistleitner. Christian is working as a contractor for Wikimedia
> Foundation specializing in Gerrit work, who started working with us in
> mid-January.  Christian was very helpful in getting the Gerrit 2.6pre
> upgrade to happen, and is working on the backlog of features that we'd
> like for Gerrit (e.g. project renames, project deletions, better
> Bugzilla integration).  He'll be working with us through the end of
> April.
> 
> Welcome Christian!
> 
> Rob

This is great!  Welcome, Christian.  Folks seeking him out on IRC should
look for "qchris".

-- 
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Extensions and LTS

2013-02-12 Thread Mark A. Hershberger

On 02/12/2013 08:14 AM, Maria Miteva wrote:
> On a brighter note, I heard that the LTS version 1.19 was the best thing
> that happened since sliced bread :)

This makes me very happy.

I'm going to start paying close attention to people who have problems
upgrading from 1.19 over the next couple of years so that when we hit
the next LTS (1.25) in 2015, we'll have fewer issues for the people
moving from 1.19 to 1.25.

I would like to ask your help with this, of course.  If you see
something that you think we should take note of and fix, let me know.

A big part of this is going to be those non-WMF extensions that people
like to use.  I'm not too worried about the popular SMW extensions --
the SMW folks have a good handle on the LTS -- but if you install an
extension with the expectation that it will be maintained for LTS
releases, you need to make sure that it is going to be supported.

I'd like to think that extensions in [[Category:Stable_extensions]] will
be maintained, but maybe that isn't right.  I certainly haven't tried
all of them against 1.19.

Developers can help out with this.  On Debian, for example, developers
can announce that they're orphaning a package and it needs a new
maintainer.  Ideally, a developer would find someone to maintain his own
extension, but if you see an orphaned extension or just don't feel like
maintaining one any more, please add {{Unmaintained extension}} to its
page on MediaWiki.org.

That said, I've created a category page on MediaWiki.org --
https://www.mediawiki.org/wiki/Category:Not_LTS_ready -- for extensions
are marked Stable but unmaintained.

(I still have to actually put pages in the category, but I'll do that
after dinner.)

Mark.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Extensions and LTS

2013-02-12 Thread David Gerard

On 12 February 2013 23:48, Mark A. Hershberger  wrote:

> I'm going to start paying close attention to people who have problems
> upgrading from 1.19 over the next couple of years so that when we hit
> the next LTS (1.25) in 2015, we'll have fewer issues for the people
> moving from 1.19 to 1.25.

Waiting that long? That'll leave Ubuntu 14.04 with 1.19 unsupportable
for a year or so. It also strikes me as a long time given the pace of
MW development. (I suppose I'd be asking a lot to ask for overlapping
LTS times.)

The rest of your post is wonderful and heartwarming stuff for a
tarball user to hear :-)

- d.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Font at dv.wikipedia and dv.wiktionary

2013-02-12 Thread M. Williamson

Doesn't MOSS stand for Maldives Open Source Society?

I can't find a lot of info on them as they don't seem to be active
online at the moment, but I did find this:

https://lists.ubuntu.com/archives/ubuntu-core-marketing/2009-June/00.html

Maybe someone could e-mail the author of that message and ask if they
can be of assistance in determining the copyright status of the font?

Based on that e-mail it appears they may be the same group as the
Maldives Linux Users Group:

http://www.mlug.mv/

Just some ideas...

2013/2/12, Mark A. Hershberger :
> On 02/12/2013 03:56 AM, oәuɐႡɔsʇnәp nɐႡsn wrote:
>> Hello. The fonts at Dhivehi Wikipedia and Wiktionary are not webfonts. If
>> possible could the fonts be changed
>> to Faruma which can be downloaded from here:
>>
> http://bazaar.launchpad.net/~mvishah/ttf-dhivehi-fonts/trunk/view/head:/ttf-thaana-fonts/faruma.ttf
>
> The copyright for that package is GPL (see
> https://bazaar.launchpad.net/~mvishah/ttf-dhivehi-fonts/trunk/view/head:/debian/copyright),
> which we could use.
>
> However, it isn't clear that the font itself is under the GPL. The
> copyright file says "downloaded from http://moss.org.mv"; but
> moss.org.mv doesn't appear to be registered currently so there is no DNS
> domain.
>
> IANAL, but I think we need to show proper provenance for the fonts
> before we can use it and right now, it looks like I'm hitting a dead end.
>
>
> --
> http://hexmode.com/
>
> There is no path to peace. Peace is the path.
>-- Mahatma Gandhi, "Non-Violence in Peace and War"
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l


-- 
skype: node.ue

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Extensions and LTS

2013-02-12 Thread Niklas Laxström

On 13 February 2013 01:48, Mark A. Hershberger  wrote:

> I'm going to start paying close attention to people who have problems
> upgrading from 1.19 over the next couple of years so that when we hit
> the next LTS (1.25) in 2015, we'll have fewer issues for the people
> moving from 1.19 to 1.25.

There is near zero chance that I will keep supporting 1.19 for that
long in master branch in all of my extensions (and this is assuming
support for 1.19 is dropped immediately when 1.25 is released). It's
already hard since 1.19 is missing some features I need.

People need to realize that they can't get the latest shiny extensions
on years old MediaWiki. For extensions this would mean that they would
create a branch with security fixes and other important bug fixes for
1.19. MLEB will probably just declare some release as the last release
that works with 1.19.

1.19 was released on 2012-02-09. For comparison Ubuntu has released
LTS version every two years.

> I'd like to think that extensions in [[Category:Stable_extensions]] will
> be maintained, but maybe that isn't right.  I certainly haven't tried
> all of them against 1.19.

Maintained doesn't necessarily mean support for 1.19 is kept.

> Developers can help out with this.  On Debian, for example, developers
> can announce that they're orphaning a package and it needs a new
> maintainer.  Ideally, a developer would find someone to maintain his own
> extension, but if you see an orphaned extension or just don't feel like
> maintaining one any more, please add {{Unmaintained extension}} to its
> page on MediaWiki.org.

Has any extension been adopted this way?

  -Niklas

--
Niklas Laxström

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

38 matches

Mail list logo