[Wikitech-l] [GSoC] tools for micromanagement

2013-05-09 Thread Yury Katkov
Hi everyone!

What tools do you use for a small tasks in Google Summer of Code? I mean
the tasks like "prepare the working environment", "learn gerrit", "write a
blogpost", etc.? I thin that bugzilla is too heavy for this purpose.

Also can we use microblogging for reporting the current progress (in
addition to posts in a blog one in 2 weeks )? I tried that once and it was
very fun and efficient.

Cheers,
-
Yury Katkov, WikiVote
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] category intersection conversations

2013-05-09 Thread Matthew Flaschen
On 05/09/2013 03:49 PM, James Forrester wrote:
> On 9 May 2013 12:40, David Gerard  wrote:
> 
>> So yeah, whatever we use to add tags needs to be able to add citations
>> as well, right there next to the tag.
>>
> 
> Well, to me that's a​n even more compelling reason create such a system
> (Categories as-is don't have them): "WikiTags let you cite the source of
> why the subject is tagged that way".

Or a reason to have all the real data in Wikiata, and have NewCategories
be a way to query Wikidata.  Wikidata already has (basic but improving)
support for adding a citation to every statement.

But this (like switching to tags) would be a big change.

Matt Flaschen

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

Re: [Wikitech-l] category intersection conversations

2013-05-09 Thread Bartosz Dziewoński
Dmitriy, yes, and that's the point - in practice Wikipedia categories
are not transitive.

We've been working on this slowly at pl.wp lately, trying to split the
categories into two kinds marked with appropriate templates: "topic"
categories, including all related entries, e.g. Category:Water; and
"object" ones, which would imply transitiveness, like the Politicians
example provided above.

Topic cats could contain object ones, but not vice versa. This seems
like a good compromise to me, but requires a good deal of work, and
we're slowly progressing.

-- 
-- Matma Rex

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

Re: [Wikitech-l] category intersection conversations

2013-05-09 Thread Dmitriy Sintsov

On 09.05.2013 20:28, Brad Jorsch wrote:

On Wed, May 8, 2013 at 10:47 PM, James Forrester
 wrote:

* Pages are implicitly in the parent categories of their explicit categories
* -> Pages in  are in  (its first parent) and  (its first parent's parent) and  (its second
parent) and  (its second parent's parent) and …
* -> Yes, this poses issues given the sometimes cyclic nature of
categories' hierarchies, but this is relatively trivial to code around

Category cycles are the least of it. The fact that the existing
category hierarchy isn't based on any sensible-for-inference ontology
is a bigger problem.

Let's consider what would happen to one of my favorite examples on enwiki:
* The article for Romania is in . Ok.
* And that category is in , so Romania is in that too.
Which is a little strange, but not too bad.
* And  is in  and .
Huh? Romania doesn't belong in either of those, despite that being
equivalent to your example where pages in  also end up in  via .


There is probably nothing contradictionary in your Black sea category 
relation example because "Seas of " implies that  has 
*multiple* seas, while Romania has only *one* sea border (no offence, 
there are lot of small countries and large country does not always means 
a happy life).  is a little bit more weird, but 
could be explained as long and complex area of Crimean peninsula. So, 
the categories actually are not so wrong.

Dmitriy


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

[Wikitech-l] [RFC] Drop XHTML 1.1

2013-05-09 Thread Daniel Friesen

This one will probably be more controversial than my RDFa 1.1 RFC.

It's time to drop support for XHTML 1.1 which effectively disables  
portions of MW's features.


https://www.mediawiki.org/wiki/Requests_for_comment/Drop_XHTML_1.1

And a commit implementing it:
https://gerrit.wikimedia.org/r/#/c/63106/

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


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

[Wikitech-l] New developments in automated testing, including mobile browsers & apps

2013-05-09 Thread Sumana Harihareswara
https://lwn.net/Articles/548910/

A summary of talks at a recent conference on test automation, with a
bunch of links for people who want to follow up and watch videos.

> A major theme was WebDriver, which is an API for automating web browsers. 
> Mozilla presented its work on WebDriver support in Gecko and extensions to 
> WebDriver to allow automated testing of FirefoxOS beyond just the 
> Gecko-powered content layer. Google talked about WebDriver support in 
> Chrome/Chromium, including Chrome on Android. Others demonstrated FOSS 
> software that re-purposes the WebDriver API for testing native mobile 
> applications on Android and iOS.

We use Selenium, which makes use of WebDriver.
https://www.mediawiki.org/wiki/QA/Roadmap has more.  I believe we are
not currently using any of the technologies mentioned to specifically
perform automated testing on mobile apps or mobile browsers, although I
could be wrong.

Chris McMahon was at this conference and may have more specific "we
should do foo" recommendations. :)

-- 
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] Next bugday: May 03rd, 15:00-16:30UTC on MediaWiki Installer issues

2013-05-09 Thread Andre Klapper
On Tue, 2013-04-30 at 14:08 +0200, Andre Klapper wrote:
> Friday, May 03rd, 15:00-16:30 UTC [1]
> in #wikimedia-office on Freenode IRC [2]
> 
> We are going to take a look at recent MediaWiki installer reports,
> trying to reproduce some plus provide feedback and prioritization.

Quick summary how it went: We managed to triage a dozen of reports
(focused on tickets with high priority), e.g. reproduced most of them
and provided more info, also closed three, and found one new bug.

Long version:
https://www.mediawiki.org/wiki/Bug_management/Triage/20130503#Results

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] HipHop VM support: ArrayObject and filter_var()

2013-05-09 Thread Tyler Romeo
On Thu, May 9, 2013 at 9:57 PM, Tim Starling wrote:

> If you can write a complete and accurate compatibility class in pure
> PHP, then it can be included in HipHop in the system/classes directory.
>

Interesting. I'll try and work on this.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] HipHop VM support: ArrayObject and filter_var()

2013-05-09 Thread Tim Starling
On 10/05/13 11:48, Tyler Romeo wrote:
> On Thu, May 9, 2013 at 9:46 PM, Tim Starling wrote:
> 
>> You can always implement the parts you need in pure PHP.
> 
> 
> True. It might be worthwhile to make some sort of Spl compatibility library
> that loads in PHP versions of those classes if they do not exists. That way
> we can use them without dropping HHVM support.

If you can write a complete and accurate compatibility class in pure
PHP, then it can be included in HipHop in the system/classes directory.

-- Tim Starling


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

Re: [Wikitech-l] HipHop VM support: ArrayObject and filter_var()

2013-05-09 Thread Tyler Romeo
On Thu, May 9, 2013 at 9:46 PM, Tim Starling wrote:

> You can always implement the parts you need in pure PHP.


True. It might be worthwhile to make some sort of Spl compatibility library
that loads in PHP versions of those classes if they do not exists. That way
we can use them without dropping HHVM support.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Coding style: Language construct spacing

2013-05-09 Thread Tyler Romeo
On Thu, May 9, 2013 at 9:22 PM, Tim Starling wrote:

> include and require return a value, so they are more like functions
> than return or print. See e.g. ResourceLoader.php:
>
> $this->register( include( "$IP/resources/Resources.php" ) );
>
> You could compare them to pseudo-functions like empty and isset. I
> suppose you could write:
>
> $this->register( include "$IP/resources/Resources.php" );
>
> But that looks kind of weird to me.
>

True, but you also have to be careful about that. As mentioned in the PHP
docs, this can lead to weird operator precedence results. For example,

if ( include( "$IP/resources/Resources.php" ) === false ) {

will not work as expected. It looks like a quick check to see if the
included file was successfully included, but PHP will first evaluate the
=== operator before the include statement.

*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2015
Major in Computer Science
www.whizkidztech.com | tylerro...@gmail.com
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] HipHop VM support: ArrayObject and filter_var()

2013-05-09 Thread Tim Starling
On 10/05/13 11:28, Daniel Friesen wrote:
> On Thu, 09 May 2013 18:10:53 -0700, Tim Starling
>  wrote:
> 
>> * SplDoublyLinkedList
>> * SplFixedArray
>> * SplHeap
>> * SplMaxHeap
>> * SplMinHeap
>> * SplPriorityQueue
>> * SplQueue
>> * SplStack
> 
> It would be nice if HHVM would support these. I'm not sure what is so
> complex about these that HHVM can implement array() but not these
> simple classes.
> 
> While working on my skin rewrite ideas, trying to implement the
> template syntax parsing was much MUCH more readable and less prone to
> mistakes (like those that would occur if php cloned the array() in a
> place it shouldn't cause I typed something wrong) when working with
> SplDoublyLinkedList, SplQueue, and SplStack.

You can always implement the parts you need in pure PHP.

-- Tim Starling




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

Re: [Wikitech-l] [RFC] Update our code to use RDFa 1.1 instead of RDFa 1.0

2013-05-09 Thread James Forrester
On 9 May 2013 18:29, Daniel Friesen  wrote:

> On Wed, 08 May 2013 03:52:07 -0700, Daniel Friesen <
> dan...@nadir-seen-fire.com> wrote:
>
>  I was going through our code contemplating dropping XHTML 1.1 support and
>> ran into the RDFa support stuff and realized how out of date and limited it
>> is.
>>
>> I've put together an RFC for replacing our code that appears to be based
>> on the RDFa 1.0 from 2008 with RDFa 1.1 and expanding support for RDFa.
>>
>> https://www.mediawiki.org/**wiki/Requests_for_comment/**
>> Update_our_code_to_use_RDFa_1.**1_instead_of_RDFa_1.0
>>
>
> Is no-one at all interested in RDFa?
>
> No opposition. No enthusiasm. No... "Just go ahead and do it"?


I'm in favour. :-) Seems a sensible change all round, and there don't
appear to be reasons against.

​J.
-- 
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

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

Re: [Wikitech-l] [RFC] Update our code to use RDFa 1.1 instead of RDFa 1.0

2013-05-09 Thread Tyler Romeo
Well I don't have any experience in RDFa, but looking at the proposal, it
seems like something we should do.

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


On Thu, May 9, 2013 at 9:29 PM, Daniel Friesen
wrote:

> On Wed, 08 May 2013 03:52:07 -0700, Daniel Friesen <
> dan...@nadir-seen-fire.com> wrote:
>
>  I was going through our code contemplating dropping XHTML 1.1 support and
>> ran into the RDFa support stuff and realized how out of date and limited it
>> is.
>>
>> I've put together an RFC for replacing our code that appears to be based
>> on the RDFa 1.0 from 2008 with RDFa 1.1 and expanding support for RDFa.
>>
>> https://www.mediawiki.org/**wiki/Requests_for_comment/**
>> Update_our_code_to_use_RDFa_1.**1_instead_of_RDFa_1.0
>>
>
> Is no-one at all interested in RDFa?
>
> No opposition. No enthusiasm. No... "Just go ahead and do it"?
>
>
> --
> ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
>
>
> __**_
> 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] [RFC] Update our code to use RDFa 1.1 instead of RDFa 1.0

2013-05-09 Thread Daniel Friesen
On Wed, 08 May 2013 03:52:07 -0700, Daniel Friesen  
 wrote:


I was going through our code contemplating dropping XHTML 1.1 support  
and ran into the RDFa support stuff and realized how out of date and  
limited it is.


I've put together an RFC for replacing our code that appears to be based  
on the RDFa 1.0 from 2008 with RDFa 1.1 and expanding support for RDFa.


https://www.mediawiki.org/wiki/Requests_for_comment/Update_our_code_to_use_RDFa_1.1_instead_of_RDFa_1.0


Is no-one at all interested in RDFa?

No opposition. No enthusiasm. No... "Just go ahead and do it"?

--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


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

Re: [Wikitech-l] HipHop VM support: ArrayObject and filter_var()

2013-05-09 Thread Daniel Friesen
On Thu, 09 May 2013 18:10:53 -0700, Tim Starling   
wrote:



* SplDoublyLinkedList
* SplFixedArray
* SplHeap
* SplMaxHeap
* SplMinHeap
* SplPriorityQueue
* SplQueue
* SplStack


It would be nice if HHVM would support these. I'm not sure what is so  
complex about these that HHVM can implement array() but not these simple  
classes.


While working on my skin rewrite ideas, trying to implement the template  
syntax parsing was much MUCH more readable and less prone to mistakes  
(like those that would occur if php cloned the array() in a place it  
shouldn't cause I typed something wrong) when working with  
SplDoublyLinkedList, SplQueue, and SplStack.



-- Tim Starling


--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


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

Re: [Wikitech-l] Coding style: Language construct spacing

2013-05-09 Thread Tim Starling
On 09/05/13 10:26, Krinkle wrote:
> I'm obviously biased, but I think the same goes for "require_once"
> (and "include", "require" etc.). Right now this is causing quite a few
> warnings in our php-checkstyle report.

include and require return a value, so they are more like functions
than return or print. See e.g. ResourceLoader.php:

$this->register( include( "$IP/resources/Resources.php" ) );

You could compare them to pseudo-functions like empty and isset. I
suppose you could write:

$this->register( include "$IP/resources/Resources.php" );

But that looks kind of weird to me.

-- Tim Starling


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

[Wikitech-l] HipHop VM support: ArrayObject and filter_var()

2013-05-09 Thread Tim Starling
Several people from the HipHop team at Facebook just met with several
people from WMF. Also, in the last couple of days, I've been doing
some research into what it would take to make MediaWiki support HipHop
VM. The answer is: not very much.

There's two features that we use, mostly in extensions, that the
Facebook people are not keen to implement due to their complexity:
ArrayObject and filter_var(). It seems that it would be much easier
for us to stop using them than for those features to be implemented in
HipHop.

So I'd like to suggest that we refuse new code submissions in Gerrit
that use these features, if they are targeted for WMF production, and
that we start work on migrating away from the existing uses of those
features.

There's a few other SPL features that we don't use at the moment and
we should avoid introducing if possible due to lack of support in HipHop:

* CachingIterator
* EmptyIterator
* GlobIterator
* InfiniteIterator
* LimitIterator
* MultipleIterator
* NoRewindIterator
* ParentIterator
* RecursiveArrayIterator
* RecursiveCachingIterator
* RecursiveFilterIterator
* RecursiveRegexIterator
* RecursiveTreeIterator
* RegexIterator
* SplDoublyLinkedList
* SplFixedArray
* SplHeap
* SplMaxHeap
* SplMinHeap
* SplPriorityQueue
* SplQueue
* SplStack
* SplTempFileObject

We are not yet promising that we are indeed going to start using
HipHop in WMF production, and we don't have any timetables. But HipHop
has evolved to the point where supporting it is almost trivial, at
least for test installations, so I think it makes sense to establish
policies which will avoid making migration to HipHop more difficult.

-- Tim Starling


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

Re: [Wikitech-l] Coding style: Language construct spacing

2013-05-09 Thread S Page
> we all copied it...

I learned the idiom require_once( 'path.php' ); from

* My wiki's LocalSettings.php , generated by
includes/installer/LocalSettingsGenerator.php
* The LocalSettings.php of labs instances, in puppet labs-localsettings
* The installation instructions for every extension on mediawiki.org

All should change.

php.net has a comment agreeing with this change: "it will prevent your
peers from giving you a hard time and a trivial conversation about what
require really is"  :-)


On Wed, May 8, 2013 at 5:26 PM, Krinkle  wrote:

> Hi,
>
> Since there appears to have been a little bit of trivia around fixing
> these phpcs warnings, I'll open a thread instead.
>
> Both in javascript and PHP there are various keywords that can be used
> as if they are functions. In my opinion this is a misuse of the
> language and only causes confusion.
>
> I'm referring to code like this (both javascript and php):
>
> delete( mw.legacy );
>
> new( mw.Title );
>
> typeof( mw );
>
> echo( $foo . $bar );
>
> print( $foo . $bar );
>
> return( $foo . $bar );
>
> … and, wait for it..
>
> require_once( $foo . $bar );
>
> I think most experienced javascript developers know by now that using
> "delete" or "new" like it is a function is just silly and looks like
> you don't know what you're doing.
>
> To give a bit of background, here's why these work at all (they aren't
> implemented both keywords and functions, just keywords). Though I'm
> sure the implementation details differ between PHP and javascript, the
> end result is the same: Keywords are given expressions which are then
> evaluated and the result is used as value. Since expressions can be
> wrapped in parenthesis for readability (or logic grouping), and since
> whitespace is insignificant to the interpreter, it is possible to do
> `return("test")`, which really is just `return ("test")` and
> eventually `return "test"`.
>
> I'm obviously biased, but I think the same goes for "require_once"
> (and "include", "require" etc.). Right now this is causing quite a few
> warnings in our php-checkstyle report.
>
> I didn't disable that rule because it appears (using our code base as
> status quo) that we do want this. There's 0 warnings I could find in
> our code base that violate this, except for when the keyword is
> include|require(_once)?
>
> The check style sniffer does not (and imho should not) have a separate
> rule per keyword. Either you use constructs like this, or you don't.
>
> But let's not have some weird exception just because someone didn't
> understand it[1] and we all copied it and want to keep it for no
> rational reason.
>
> Because that would mean we have to either hack the sniffer to exclude
> this somehow, or we need to disable the rule, thus not catching the
> ones we do use.
>
> See pending change in gerrit that does a quick pass of (most of) these
> in mediawiki/core:
>
> https://gerrit.wikimedia.org/r/62753
>
>
> -- Krinkle
>
> [1] Or whatever the reason is the author originally wrote it like
> this. Perhaps PHP was different back then, or perhaps there was a
> different coding style.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
=S Page  software engineer on E3
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feasibility question: Posting mailing list notifications to a wiki page

2013-05-09 Thread Risker
I can certainly understand the frustration of developers, staff and
volunteer, in trying to find a good way to communicate with the very
diverse communities about changes.  The number of volunteer testers is
small (and often tending toward the technically highly literate), the
potential number of venues is very large and multi-lingual, and it is often
difficult to sort out "dinosaur" responses to change from those that are
valid concerns.

I don't have any perfect answers here, but whatever decision is made, I'd
urge that the following be considered when communicating about changes,
particularly anything that is noticeable to an editor without any technical
knowledge:


   - "Communication" implies that there is an opportunity for the recipient
   to respond, whether with questions, suggestions, or concerns. Whatever
   process is selected should accommodate that.
   - Any notifications about change, particularly to the UI or to content
   handling, should clearly explain what is new, what will be removed, why the
   decision was made to make the change, how the change will affect
   accessibility (e.g., screen readers) and usability, and who to contact with
   questions/suggestions/concerns. Any opt-out processes should also be
   clearly indicated.
   - When making changes and communicating about them, always be clear who
   the customer is, and remember to keep focus on that. The "customer" may be
   readers, unregistered users, registered users, a key organizational process
   (e.g., accessibility, security), a project, or some other entity.  Where
   possible, involve the customer in the public discussion about the change.
   - Remember that the majority of "visible" changes will affect people
   (readers and users) who have very limited technical knowledge; write in
   plain language without jargon. Get someone with limited techie vocabulary
   and understanding to copy edit your communication.

These are useful, and fairly standard, communication processes.  Here's
hoping that a good solution can be found, for everyone's sake.


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

[Wikitech-l] test: Jenkins crashed again today

2013-05-09 Thread Antoine Musso
Hello,

Jenkins crashed again today. The first time at 6am UTC, I got it fixed.
And again between 9pm and 10pm UTC.

This has been a recurring event since we have upgraded our installation
and the bug is:
 https://bugzilla.wikimedia.org/show_bug.cgi?id=48025

Tonight I got Jenkins access log enabled and made Zuul query jenkins
directly instead of passing via SSL + an Apache frontend proxy.  That
will help a little bit.

The root cause is some weird issue in Jenkins where one of its thread
will use 100% CPU.  I have yet to determine what that thread is doing
though nor what trigger the exact issue.  Whenever I get some useful
informations I will fill a bug upstream and make sure it get attention.

Next secret plan: get rid of Jenkins..

-- 
Antoine "hashar" Musso


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

[Wikitech-l] Recursive merging enabled for Gerrit repositories

2013-05-09 Thread Chad
Hi,

We've enabled JGit's recursive merger for all repositories using content merge
strategies (basically any not using fast forwarding, which is most).
The intention
is to lower the number of trivial conflicts that people are having to
resolve locally.

This is considered experimental by Gerrit, but is now the default for
JGit itself, so
I believe it's stable enough for us to use. That being said, it's
still new-ish so there's
always a chance we'll hit some bug. So, if you see anything, ANYTHING related to
merge problems then I'd like to know about it so we can either get it
fixed or turn the
feature back off (if it's patently broken).

Thanks!

-Chad

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

Re: [Wikitech-l] category intersection conversations

2013-05-09 Thread Sumana Harihareswara
On 05/09/2013 03:07 PM, Brian Wolff wrote:

> Just change mediawiki:pagecategories to "tags" and change some social
> conventions - boom you have tags.

Just a reminder - customs and assumptions are sometimes harder to change
than digital or physical environments.

-- 
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] category intersection conversations

2013-05-09 Thread James Forrester
On 9 May 2013 12:40, David Gerard  wrote:

> So yeah, whatever we use to add tags needs to be able to add citations
> as well, right there next to the tag.
>

Well, to me that's a​n even more compelling reason create such a system
(Categories as-is don't have them): "WikiTags let you cite the source of
why the subject is tagged that way".

​J.​
-- 
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

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

Re: [Wikitech-l] category intersection conversations

2013-05-09 Thread David Gerard
On 9 May 2013 19:21, Luke Welling WMF  wrote:

> With tags, a biography could relatively uncontroversially  be tagged as
> "Novelist, Woman, Best Selling, American, Blonde Haired, Enjoys Spicy Food"
> even if nearly everybody agrees that half the tags while true are entirely
> unimportant and not relevant to the subject's area of notability.  Whether
> some tags like race and appearance should exist at all may still generate
> debate, but if they are only ever available modifiers and not hard
> categories their offense would be softened.


It appears sir is less than entirely familiar with Wikipedia edit
wars. There is NO dispute that will not lead to six months of
wikidrama.

So yeah, whatever we use to add tags needs to be able to add citations
as well, right there next to the tag.


- d.

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

Re: [Wikitech-l] automatic extraction of wikipedia entries

2013-05-09 Thread Pierre Jourlin
Lars Aronsson  aronsson.se> writes:

> 
> Hi Pierre,
> 
> > You are invited to test my demonstration at :
> > http://dev.termwatch.es/~jourlin/demo.php
> 
> I get this message:
> 
> A username and password are being requested by http://dev.termwatch.es. 
> The site says: "Par invitation seuleument / By invitation only / Solo 
> con autentificacion"
> 

Sorry about that. Use master as the username and sitnosh as the password.
Thanks for your time !



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

Re: [Wikitech-l] category intersection conversations

2013-05-09 Thread Brian Wolff
On 2013-05-09 4:13 PM, "James Forrester"  wrote:
>
> On 9 May 2013 12:07, Brian Wolff  wrote:
>
> > Nobody has ever been able to explain to me the technical difference
between
> > tag and category. (Other than being able to query intersections, which
is
> > wanted for cats anyhow)
> >
>
> The theory is that tags are non-hierarchical, casually-applied and
> well-supported in software (from intersections to more). You can see how
> people feel what we have is somewhat different from this world vision. :-)
>
> J.
> --
> James D. Forrester
> Product Manager, VisualEditor
> Wikimedia Foundation, Inc.
>
> jforres...@wikimedia.org | @jdforrester
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Categories can be flat if people want them to be. Categories can be casual
if people want them to be (guess the red link discourages but that's
trivial to change)

People seem to want lots of things. When it comes to the tag camp, other
than non-crappy category intersection, we seem to have the things people
want, which confuses me why people are asking for them.

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

Re: [Wikitech-l] Purging parts of varnish cache

2013-05-09 Thread Arthur Richards
On Thu, May 9, 2013 at 12:19 PM, Yuri Astrakhan wrote:

> ESI for older browsers, and JavaScript otherwise are still on the table,
> but that's orthogonal to the varnish cache purge -- if we use ESI, the
> banner will be cached and will need to be purged. If we use JavaScript, the
> JSON configuration blob will need to be purged. The only difference is the
> actual "purging expression".
>

For sure; I just wanted to make sure. While practically these may be
orthogonal, purging full pages is less desirable than purging html chunks
for banners so approaching the problem with this in mind might make it all
more palatable.

-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Purging parts of varnish cache

2013-05-09 Thread Yuri Astrakhan
ESI for older browsers, and JavaScript otherwise are still on the table,
but that's orthogonal to the varnish cache purge -- if we use ESI, the
banner will be cached and will need to be purged. If we use JavaScript, the
JSON configuration blob will need to be purged. The only difference is the
actual "purging expression".


On Thu, May 9, 2013 at 2:14 PM, Arthur Richards wrote:

> Previously we had spoken about implementing partial page caching (ESI) for
> Zero so we could remove X-CS variance for article content and use it only
> for partner banners. Is this still being pursued?
>
>
> On Wed, May 8, 2013 at 10:24 PM, Yuri Astrakhan  >wrote:
>
> > Hi, when we edit Zero configuration, it would be very beneficial to flush
> > any cached pages in varnish that are related to the change.
> >
> > For example, if I edit Beeline's banner settings, any objects with the
> > header X-CS=250-99 should be purged, hopefully without any additional
> > manual interaction. Without this purge, the cache will be stale for the
> > next 30 days for the most common articles.
> >
> > Now, according to the
> > http://giantdorks.org/alain/exploring-methods-to-purge-varnish-cache/,
> > varnish has an extensive matching support, and the author provides some
> > PHP-based code to perform the cache flushing.  What would we need to
> > implement secure, automated partial varnish flushing in production?
> >
> > Thanks!
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
>
> --
> Arthur Richards
> Software Engineer, Mobile
> [[User:Awjrichards]]
> IRC: awjr
> +1-415-839-6885 x6687
> ___
> 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] category intersection conversations

2013-05-09 Thread James Forrester
On 9 May 2013 12:07, Brian Wolff  wrote:

> Nobody has ever been able to explain to me the technical difference between
> tag and category. (Other than being able to query intersections, which is
> wanted for cats anyhow)
>

​The theory is that tags are non-hierarchical, casually-applied​ and
well-supported in software (from intersections to more). You can see how
people feel what we have is somewhat different from this world vision. :-)

​J.​
-- 
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

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

Re: [Wikitech-l] category intersection conversations

2013-05-09 Thread Brian Wolff
On 2013-05-09 3:21 PM, "Luke Welling WMF"  wrote:
>
> Without deliberately making it an even longer term plan, as I think it is
a
> great idea, another long goal solution to the same problem would be (as
> Flow gets Wikipedians into the idea of tagging) that categories get
largely
> replaced by tags.  That way they lose much of their absoluteness and
> therefore some of their controversy.
>
> Categories are hard for Wikipedia because compromise is not possible.
>  Consensus can be reached on a subtly different compromise version of the
> wording of a sentence or paragraph, but there is no compromise on
> categories.  A category either exists or does not. A page either goes in
or
> does not.
>
> With tags, a biography could relatively uncontroversially  be tagged as
> "Novelist, Woman, Best Selling, American, Blonde Haired, Enjoys Spicy
Food"
> even if nearly everybody agrees that half the tags while true are entirely
> unimportant and not relevant to the subject's area of notability.  Whether
> some tags like race and appearance should exist at all may still generate
> debate, but if they are only ever available modifiers and not hard
> categories their offense would be softened.
>
> For some subjects, entirely uncontroversial tags could be extracted from
> Wikidata.
>
> It would be content shakeup and therefore perhaps politically difficult,
> but it would take a lot of the technical challenge out of joins, even
> permitting joins (automatically or manually) with tags translated into
> equivalent versions in other languages.
>
> All possible combinations of tag derived categories would then "exist",
and
> it would just be a matter of debate as to whether there is a justification
> to add a link from a page to "Biography+Novelist+Enjoys Spicy Food" or if
> that is a meaningless category.  If reverted, the one person interested in
> that exact category could still always visit it, it's just that other
users
> would not be directed to it unless they probe talk page debates.
>
> Luke Welling
>
>

Nobody has ever been able to explain to me the technical difference between
tag and category. (Other than being able to query intersections, which is
wanted for cats anyhow)

Just change mediawiki:pagecategories to "tags" and change some social
conventions - boom you have tags.

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

Re: [Wikitech-l] Feasibility question: Posting mailing list notifications to a wiki page

2013-05-09 Thread Quim Gil

This is a cool idea.

On 05/09/2013 06:19 AM, Guillaume Paumier wrote:

What I currently have in mind is a bot subscribed to the
wikitech-ambassadors list, that would post every first message of a
thread to the talk page of people who have signed up (like
https://meta.wikimedia.org/wiki/Global_message_delivery/Targets/Tech_ambassadors
) or to a noticeboard (that would then be mostly automated).


Let's abstract this a bit more:

A bot subscribed to a mailing list that
* posts the subject and body of a new thread in a wiki page.
* posts notifications to users subscribed to the bot.

Echo seems to be ripe enough to go for it instead of the old system of 
populating User Talk pages.




The bot would create a new section, using the email's subject line as
the section title, and its body as the message. It would ideally link
back to the gmane archive for that thread, so that users can read
follow-up messages there. Messages could be trimmed if they're too
long. The system could possibly also be used for other mailing lists
later.


And a way to archive old posts?

We could also use such bot for posting wikitech-announce updates at 
mediawiki.org.


PS: I hope this idea doesn't die after a few days, but if it starts 
fading out let's slap it at 
http://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects


--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil

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

Re: [Wikitech-l] category intersection conversations

2013-05-09 Thread Luke Welling WMF
Without deliberately making it an even longer term plan, as I think it is a
great idea, another long goal solution to the same problem would be (as
Flow gets Wikipedians into the idea of tagging) that categories get largely
replaced by tags.  That way they lose much of their absoluteness and
therefore some of their controversy.

Categories are hard for Wikipedia because compromise is not possible.
 Consensus can be reached on a subtly different compromise version of the
wording of a sentence or paragraph, but there is no compromise on
categories.  A category either exists or does not. A page either goes in or
does not.

With tags, a biography could relatively uncontroversially  be tagged as
"Novelist, Woman, Best Selling, American, Blonde Haired, Enjoys Spicy Food"
even if nearly everybody agrees that half the tags while true are entirely
unimportant and not relevant to the subject's area of notability.  Whether
some tags like race and appearance should exist at all may still generate
debate, but if they are only ever available modifiers and not hard
categories their offense would be softened.

For some subjects, entirely uncontroversial tags could be extracted from
Wikidata.

It would be content shakeup and therefore perhaps politically difficult,
but it would take a lot of the technical challenge out of joins, even
permitting joins (automatically or manually) with tags translated into
equivalent versions in other languages.

All possible combinations of tag derived categories would then "exist", and
it would just be a matter of debate as to whether there is a justification
to add a link from a page to "Biography+Novelist+Enjoys Spicy Food" or if
that is a meaningless category.  If reverted, the one person interested in
that exact category could still always visit it, it's just that other users
would not be directed to it unless they probe talk page debates.

Luke Welling


On Thu, May 9, 2013 at 12:38 PM, James Forrester
wrote:

> [I worry we're talking about operational details, which should be a wider
> discussion, rather than a technology/feasibility conversation to which this
> list is more suited. Perhaps moving this on-wiki would be best?]
>
> On 9 May 2013 09:28, Brad Jorsch  wrote:
>
> > On Wed, May 8, 2013 at 10:47 PM, James Forrester
> >  wrote:
> > > * Pages are implicitly in the parent categories of their explicit
> > categories
> > > * -> Pages in  are in  the
> > > Netherlands by profession> (its first parent) and  > > Netherlands> (its first parent's parent) and  (its second
> > > parent) and  (its second parent's parent) and …
> > > * -> Yes, this poses issues given the sometimes cyclic nature of
> > > categories' hierarchies, but this is relatively trivial to code around
> >
> > Category cycles are the least of it. The fact that the existing
> > category hierarchy isn't based on any sensible-for-inference ontology
> > is a bigger problem.
> >
> > Let's consider what would happen to one of my favorite examples on
> enwiki:
> > * The article for Romania is in . Ok.
> > * And that category is in , so Romania is in that too.
> > Which is a little strange, but not too bad.
> > * And  is in  and .
> > Huh? Romania doesn't belong in either of those, despite that being
> > equivalent to your example where pages in  > Netherlands> also end up in  via .
> >
> > And it gets worse the further up you go. You would have Romania in
> >  a few more levels up.
> >
> > For this to work, each wiki would have to redo its category hierarchy
> > as a real ontology based on is-a relationships, rather than the
> > current is-somehow-related-to. Or we would have to introduce some
> > magic word or something to tell MediaWiki that  is-a
> >  is a valid inference while  is-a  > Sea> isn't.
> >
> > In other words, code-wise adding "tags" to an article is the same as
> > categories with inference and querying. But trying to use the existing
> > category setup as it exists on something like enwiki as "tags" for
> > inference (or querying, to a lesser extent) seems like GIGO.
> >
>
> Quite - the bit of my proposal where the categories would get created on
> Wikidata from scratch as a synthesis of the needs of the editing community.
> :-)
>
> Implicitly, these would have clear semantics about the correctitude of
> their usage governed by something analogous to how Wikidata's community are
> managing the roll-out of statements on the system. In terms of tools to
> prevent this becoming an issue, Wikidata's nature means we could easily
> make sure that the domain of a category would be limited (e.g. "Fluids"
> maps to "substances", not "instances of substances").
>
>
>
> > > * Readers can search, querying across categories regardless of whether
> > > they're implicit or explicit
> > > * -> A search for the intersection of 
> with
> > >  will effectively return results for  > > Netherlands> (and the user doesn't need to know or care that this is an
> > > extant or non-extant category)
> >
> > A person who is originally fr

Re: [Wikitech-l] Purging parts of varnish cache

2013-05-09 Thread Arthur Richards
Previously we had spoken about implementing partial page caching (ESI) for
Zero so we could remove X-CS variance for article content and use it only
for partner banners. Is this still being pursued?


On Wed, May 8, 2013 at 10:24 PM, Yuri Astrakhan wrote:

> Hi, when we edit Zero configuration, it would be very beneficial to flush
> any cached pages in varnish that are related to the change.
>
> For example, if I edit Beeline's banner settings, any objects with the
> header X-CS=250-99 should be purged, hopefully without any additional
> manual interaction. Without this purge, the cache will be stale for the
> next 30 days for the most common articles.
>
> Now, according to the
> http://giantdorks.org/alain/exploring-methods-to-purge-varnish-cache/,
> varnish has an extensive matching support, and the author provides some
> PHP-based code to perform the cache flushing.  What would we need to
> implement secure, automated partial varnish flushing in production?
>
> Thanks!
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Feasibility question: Posting mailing list notifications to a wiki page

2013-05-09 Thread Arthur Richards
This might be something that would be better suited for Echo rather than
talk page notifications.


On Thu, May 9, 2013 at 9:26 AM, Guillaume Paumier wrote:

> On Thu, May 9, 2013 at 6:20 PM, Guillaume Paumier
>  wrote:
> >
> > Perhaps using email subjects starting with "Please relay: " would
> > be a first step, but I don't expect it to be enough. I'm open to
> > suggestions about how to increase that ratio :)
>
> Another possibility would be (if we set up that mailing-list-to-wiki
> bot) to test whether people who get the message on their talk page
> relay it more than people who get it via email.
>
> (My intuition would be yes, because they're already in the "wiki"
> activity and not in the "email" one, but perhaps I'm just projecting
> my own personal processes here.)
>
> --
> Guillaume Paumier
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Arthur Richards
Software Engineer, Mobile
[[User:Awjrichards]]
IRC: awjr
+1-415-839-6885 x6687
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [Engineering] Testing and monitoring deployed code

2013-05-09 Thread Greg Grossmeier
Hello all,


> On Tuesday, April 23, 2013 at 1:06 PM, Greg Grossmeier wrote:
> > 
> > On the [[How to deploy code]] wikitech page, there is a section on
> > Testing your live code:
> > https://wikitech.wikimedia.org/wiki/How_to_deploy_code#Test_your_code_live
> > 
> > That's a pretty basic overview of it and it could be greatly improved
> > with information like:
> > * How to monitor specific parts of the cluster that are relevant to what
> > you deployed
> > * What general monitoring should be looked at after you deploy
> 
> 
> MediaWiki exceptions / fatals are plotted in Ganglia now, though somewhat 
> awkwardly under node vanadium.eqiad.wmnet (where they're getting tallied) 
> rather than the node on which the error originated. I think the way it's done 
> now deserves another thought (maybe this ought to go in graphite, instead?), 
> but at the same time it is sufficiently intelligible to be of _some_ use, I 
> think.
> 
> The most useful view is the last two hour's worth of exceptions and misc. 
> fatals (evergreen link):
> 
> http://ganglia.wikimedia.org/latest/graph.php?r=2hr&z=xlarge&title=MediaWiki+errors&vl=errors+%2F+sec&x=0.5&n=&hreg[]=vanadium.eqiad.wmnet&mreg[]=fatal%7Cexception>ype=stack&glegend=show&aggregate=1&embed=1
> 
> (The m is 'mili', so the current peaks correspond to one exception / fatal 
> every 6-10 seconds.)
> 
> I'll add it to the post-deployment instructions if people find it useful.

Ori added that, and I believe S Page added some more info to that
section.

https://wikitech.wikimedia.org/wiki/How_to_deploy_code#Test_and_monitor_your_live_code

How does it look? Anyone here have any corrections and/or additions that
aren't represented there yet?

Thanks,

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

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

Re: [Wikitech-l] category intersection conversations

2013-05-09 Thread James Forrester
[I worry we're talking about operational details, which should be a wider
discussion, rather than a technology/feasibility conversation to which this
list is more suited. Perhaps moving this on-wiki would be best?]

On 9 May 2013 09:28, Brad Jorsch  wrote:

> On Wed, May 8, 2013 at 10:47 PM, James Forrester
>  wrote:
> > * Pages are implicitly in the parent categories of their explicit
> categories
> > * -> Pages in  are in  > Netherlands by profession> (its first parent) and  > Netherlands> (its first parent's parent) and  (its second
> > parent) and  (its second parent's parent) and …
> > * -> Yes, this poses issues given the sometimes cyclic nature of
> > categories' hierarchies, but this is relatively trivial to code around
>
> Category cycles are the least of it. The fact that the existing
> category hierarchy isn't based on any sensible-for-inference ontology
> is a bigger problem.
>
> Let's consider what would happen to one of my favorite examples on enwiki:
> * The article for Romania is in . Ok.
> * And that category is in , so Romania is in that too.
> Which is a little strange, but not too bad.
> * And  is in  and .
> Huh? Romania doesn't belong in either of those, despite that being
> equivalent to your example where pages in  Netherlands> also end up in  via .
>
> And it gets worse the further up you go. You would have Romania in
>  a few more levels up.
>
> For this to work, each wiki would have to redo its category hierarchy
> as a real ontology based on is-a relationships, rather than the
> current is-somehow-related-to. Or we would have to introduce some
> magic word or something to tell MediaWiki that  is-a
>  is a valid inference while  is-a  Sea> isn't.
>
> In other words, code-wise adding "tags" to an article is the same as
> categories with inference and querying. But trying to use the existing
> category setup as it exists on something like enwiki as "tags" for
> inference (or querying, to a lesser extent) seems like GIGO.
>

Quite - the bit of my proposal where the categories would get created on
Wikidata from scratch as a synthesis of the needs of the editing community.
:-)

Implicitly, these would have clear semantics about the correctitude of
their usage governed by something analogous to how Wikidata's community are
managing the roll-out of statements on the system. In terms of tools to
prevent this becoming an issue, Wikidata's nature means we could easily
make sure that the domain of a category would be limited (e.g. "Fluids"
maps to "substances", not "instances of substances").



> > * Readers can search, querying across categories regardless of whether
> > they're implicit or explicit
> > * -> A search for the intersection of  with
> >  will effectively return results for  > Netherlands> (and the user doesn't need to know or care that this is an
> > extant or non-extant category)
>
> A person who is originally from the Netherlands but moved to Germany
> and became a politician there would be in  Netherlands> and , but maybe should not be in
>  depending on how exactly you define
> that category.
>

​Indeed; I deliberately chose to use 
rather than ​ or  which are distinct categories with entirely different
semantics, but you're right that semantics would need to be clear.

​J.
-- 
James D. Forrester
Product Manager, VisualEditor
Wikimedia Foundation, Inc.

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

Re: [Wikitech-l] category intersection conversations

2013-05-09 Thread Brad Jorsch
On Wed, May 8, 2013 at 10:47 PM, James Forrester
 wrote:
> * Pages are implicitly in the parent categories of their explicit categories
> * -> Pages in  are in  Netherlands by profession> (its first parent) and  Netherlands> (its first parent's parent) and  (its second
> parent) and  (its second parent's parent) and …
> * -> Yes, this poses issues given the sometimes cyclic nature of
> categories' hierarchies, but this is relatively trivial to code around

Category cycles are the least of it. The fact that the existing
category hierarchy isn't based on any sensible-for-inference ontology
is a bigger problem.

Let's consider what would happen to one of my favorite examples on enwiki:
* The article for Romania is in . Ok.
* And that category is in , so Romania is in that too.
Which is a little strange, but not too bad.
* And  is in  and .
Huh? Romania doesn't belong in either of those, despite that being
equivalent to your example where pages in  also end up in  via .

And it gets worse the further up you go. You would have Romania in
 a few more levels up.

For this to work, each wiki would have to redo its category hierarchy
as a real ontology based on is-a relationships, rather than the
current is-somehow-related-to. Or we would have to introduce some
magic word or something to tell MediaWiki that  is-a
 is a valid inference while  is-a  isn't.

In other words, code-wise adding "tags" to an article is the same as
categories with inference and querying. But trying to use the existing
category setup as it exists on something like enwiki as "tags" for
inference (or querying, to a lesser extent) seems like GIGO.

> * Readers can search, querying across categories regardless of whether
> they're implicit or explicit
> * -> A search for the intersection of  with
>  will effectively return results for  Netherlands> (and the user doesn't need to know or care that this is an
> extant or non-extant category)

A person who is originally from the Netherlands but moved to Germany
and became a politician there would be in  and , but maybe should not be in
 depending on how exactly you define
that category.


-- 
Brad Jorsch
Software Engineer
Wikimedia Foundation

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

Re: [Wikitech-l] Feasibility question: Posting mailing list notifications to a wiki page

2013-05-09 Thread Guillaume Paumier
On Thu, May 9, 2013 at 6:20 PM, Guillaume Paumier
 wrote:
>
> Perhaps using email subjects starting with "Please relay: " would
> be a first step, but I don't expect it to be enough. I'm open to
> suggestions about how to increase that ratio :)

Another possibility would be (if we set up that mailing-list-to-wiki
bot) to test whether people who get the message on their talk page
relay it more than people who get it via email.

(My intuition would be yes, because they're already in the "wiki"
activity and not in the "email" one, but perhaps I'm just projecting
my own personal processes here.)

--
Guillaume Paumier

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

Re: [Wikitech-l] Switching database from mysql to Oracle

2013-05-09 Thread Chad
MSSQL support is completely unmaintained.

-Chad
On May 9, 2013 12:09 PM, "Beebe, Mary J"  wrote:

> Thanks for your very quick response.
>
> What about MSSQL?
>
> Thanks,
>
> Mary Beebe
> Battelle - Charlottesville, VA
> Office: 434- 951-2149
>
>
> -Original Message-
> From: wikitech-l-boun...@lists.wikimedia.org [mailto:
> wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Freako F.
> Freakolowsky
> Sent: Thursday, May 09, 2013 11:43 AM
> To: wikitech-l@lists.wikimedia.org
> Subject: Re: [Wikitech-l] Switching database from mysql to Oracle
>
> Well supported? ... i do try my best :D
>
> I'm running a few farms on 1.17 and some standalones on 1.19 (i think?!),
> but i'm in the process of switching all of them to 1.21 once it's
> officially out and i manage to port some of our in-house extensions.
> Oracle versions on all of them have just been upgraded to 11g R2
> (11.2.0.3) SE,  but they used to run on most versions from 10g R2
> (10.2.0.2) onward.
>
> I'd suggest you go with the 1.20 or better yet wait for 1.21. You'll also
> have to up PHP to 5.3+.
>
>
> LP, Jure
>
>
> On 09. 05. 2013 17:30, Beebe, Mary J wrote:
> > We have to switch our database from mysql to Oracle or msSql.  We notice
> that there is a  DatabaseOracle.php in the db folder.  Is Oracle or MsSQL
> supported well with mediaWiki?
> >
> > Below is our current versions:
> > MediaWiki
> >
> > 1.15.3
> >
> > PHP
> >
> > 5.2.8 (cgi-fcgi)
> >
> > MySQL
> >
> > 5.5.19
> >
> >
> > We know we are not current with our mediaWiki version.  From the little
> we read the older versions may work better than the newer versions.  We are
> willing to switch to whichever version of the software that works the best
> with Oracle or MsSQL.
> >
> > Could you also point me to documentation on the databases?  At this time
> we are not concerned about the 3rd party extensions that we have installed.
>  We are more concerned about the core code.
> >
> > Thanks,
> > Mary Beebe
> > Battelle - Charlottesville, VA
> > Office: 434- 951-2149
> >
> >
> > ___
> > 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 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] Feasibility question: Posting mailing list notifications to a wiki page

2013-05-09 Thread Guillaume Paumier
On Thu, May 9, 2013 at 6:11 PM, Greg Grossmeier  wrote:
>
> I think the only way to address that is to have those on -ambassadors
> translate/localize (in more than just which language is being used) and
> post it on their local project's VPT (or equivalent).

I completely agree, and theoretically, that's how the ambassadors list
is intended to work. But in practice, my impression is that only some
of the subscribers relay the information to their local wiki.

Perhaps using email subjects starting with "Please relay: " would
be a first step, but I don't expect it to be enough. I'm open to
suggestions about how to increase that ratio :)

--
Guillaume Paumier

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

Re: [Wikitech-l] automatic extraction of wikipedia entries

2013-05-09 Thread Lars Aronsson

Hi Pierre,


You are invited to test my demonstration at :
http://dev.termwatch.es/~jourlin/demo.php


I get this message:

A username and password are being requested by http://dev.termwatch.es. 
The site says: "Par invitation seuleument / By invitation only / Solo 
con autentificacion"



--
  Lars Aronsson (l...@aronsson.se)
  Aronsson Datateknik - http://aronsson.se



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

Re: [Wikitech-l] Feasibility question: Posting mailing list notifications to a wiki page

2013-05-09 Thread Greg Grossmeier

> What I currently have in mind is a bot subscribed to the
> wikitech-ambassadors list, that would post every first message of a
> thread to the talk page of people who have signed up (like
> https://meta.wikimedia.org/wiki/Global_message_delivery/Targets/Tech_ambassadors
> ) or to a noticeboard (that would then be mostly automated).

I like this idea as it makes less work for me, theoretically ;-) (versus
the theoretical option of me needing to also post to the proposed
noticeboard).

But, it still doesn't address one of my concerns (and it isn't your
fault), from my comment on the proposal:

  I hoped those on -ambassadors could do much of the actual
  dissemination on the various 'pedias/projects because having someone
  local to the wiki, both in language and in expertise, is better at
  communicating what the real issues/changes will be for that community
  specifically, whereas I have to be fairly general for the exact
  opposite reasons (I'm English-only and not an expert in all the
  projects' methods/standards).

I think the only way to address that is to have those on -ambassadors
translate/localize (in more than just which language is being used) and
post it on their local project's VPT (or equivalent).


How the noticeboard proposal will affect me personally (vis a vis the
weekly deployment highlights email):
A) send the raw info to wikitech
B) send a generalized version to -ambassadors
C) send a ENWP-specific version to this noticeboard

Versus what I do now/would do with your proposal:
A) send the raw info to wikitech
B) send a generalized version to -ambassadors


Just my thinking on the issue as a whole,

Greg

-- 
| Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @gregA18D 1138 8E47 FAC8 1C7D |

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

Re: [Wikitech-l] Switching database from mysql to Oracle

2013-05-09 Thread Beebe, Mary J
Thanks for your very quick response. 

What about MSSQL? 

Thanks,

Mary Beebe
Battelle - Charlottesville, VA
Office: 434- 951-2149


-Original Message-
From: wikitech-l-boun...@lists.wikimedia.org 
[mailto:wikitech-l-boun...@lists.wikimedia.org] On Behalf Of Freako F. 
Freakolowsky
Sent: Thursday, May 09, 2013 11:43 AM
To: wikitech-l@lists.wikimedia.org
Subject: Re: [Wikitech-l] Switching database from mysql to Oracle

Well supported? ... i do try my best :D

I'm running a few farms on 1.17 and some standalones on 1.19 (i think?!), but 
i'm in the process of switching all of them to 1.21 once it's officially out 
and i manage to port some of our in-house extensions.
Oracle versions on all of them have just been upgraded to 11g R2
(11.2.0.3) SE,  but they used to run on most versions from 10g R2
(10.2.0.2) onward.

I'd suggest you go with the 1.20 or better yet wait for 1.21. You'll also have 
to up PHP to 5.3+.


LP, Jure


On 09. 05. 2013 17:30, Beebe, Mary J wrote:
> We have to switch our database from mysql to Oracle or msSql.  We notice that 
> there is a  DatabaseOracle.php in the db folder.  Is Oracle or MsSQL 
> supported well with mediaWiki?
>
> Below is our current versions:
> MediaWiki
>
> 1.15.3
>
> PHP
>
> 5.2.8 (cgi-fcgi)
>
> MySQL
>
> 5.5.19
>
>
> We know we are not current with our mediaWiki version.  From the little we 
> read the older versions may work better than the newer versions.  We are 
> willing to switch to whichever version of the software that works the best 
> with Oracle or MsSQL.
>
> Could you also point me to documentation on the databases?  At this time we 
> are not concerned about the 3rd party extensions that we have installed.  We 
> are more concerned about the core code.
>
> Thanks,
> Mary Beebe
> Battelle - Charlottesville, VA
> Office: 434- 951-2149
>
>
> ___
> 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 mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Switching database from mysql to Oracle

2013-05-09 Thread Freako F. Freakolowsky

Well supported? ... i do try my best :D

I'm running a few farms on 1.17 and some standalones on 1.19 (i 
think?!), but i'm in the process of switching all of them to 1.21 once 
it's officially out and i manage to port some of our in-house extensions.
Oracle versions on all of them have just been upgraded to 11g R2 
(11.2.0.3) SE,  but they used to run on most versions from 10g R2 
(10.2.0.2) onward.


I'd suggest you go with the 1.20 or better yet wait for 1.21. You'll 
also have to up PHP to 5.3+.



LP, Jure


On 09. 05. 2013 17:30, Beebe, Mary J wrote:

We have to switch our database from mysql to Oracle or msSql.  We notice that 
there is a  DatabaseOracle.php in the db folder.  Is Oracle or MsSQL supported 
well with mediaWiki?

Below is our current versions:
MediaWiki

1.15.3

PHP

5.2.8 (cgi-fcgi)

MySQL

5.5.19


We know we are not current with our mediaWiki version.  From the little we read 
the older versions may work better than the newer versions.  We are willing to 
switch to whichever version of the software that works the best with Oracle or 
MsSQL.

Could you also point me to documentation on the databases?  At this time we are 
not concerned about the 3rd party extensions that we have installed.  We are 
more concerned about the core code.

Thanks,
Mary Beebe
Battelle - Charlottesville, VA
Office: 434- 951-2149


___
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] Switching database from mysql to Oracle

2013-05-09 Thread Beebe, Mary J
We have to switch our database from mysql to Oracle or msSql.  We notice that 
there is a  DatabaseOracle.php in the db folder.  Is Oracle or MsSQL supported 
well with mediaWiki?

Below is our current versions:
MediaWiki

1.15.3

PHP

5.2.8 (cgi-fcgi)

MySQL

5.5.19


We know we are not current with our mediaWiki version.  From the little we read 
the older versions may work better than the newer versions.  We are willing to 
switch to whichever version of the software that works the best with Oracle or 
MsSQL.

Could you also point me to documentation on the databases?  At this time we are 
not concerned about the 3rd party extensions that we have installed.  We are 
more concerned about the core code.

Thanks,
Mary Beebe
Battelle - Charlottesville, VA
Office: 434- 951-2149


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

Re: [Wikitech-l] APIStrat conference, San Francisco, October 23, 24, 25

2013-05-09 Thread Vanessa Ramos
> I actually had an API talk planned for WM 2012 that I never got a chance
> to present, I could dust it off and see how well it fits in their scope.
>  Do you know when their CFP opens?
> 
Hi Marc, you can send your proposal (title and abstract) 
to me directly vane...@3scale.net
Looking forward to it!



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

Re: [Wikitech-l] APIStrat conference, San Francisco, October 23, 24, 25

2013-05-09 Thread Vanessa Ramos
> I actually had an API talk planned for WM 2012 that I never got a chance
> to present, I could dust it off and see how well it fits in their scope.
>  Do you know when their CFP opens?
> 

>> Hi Marc, that would be awesome. You can send your proposal 
(title and abstract) to me directly vane...@3scale.net. 
Looking forward to it!



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

Re: [Wikitech-l] APIStrat conference, San Francisco, October 23, 24, 25

2013-05-09 Thread Vanessa Ramos
> Will the event be recorded and broadcasted? This may be an interesting
> document to add on meta where efforts are done to make developers
> involvement more attractive.

>> It will be recorded and broadcasted and we will 
be able to share the materials. 
We don't know just yet if it will also be streamed online.
-Vanessa


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

[Wikitech-l] Fwd: Wikidata Features

2013-05-09 Thread Puneet Kaur
Hi Sumana,

Thanks for replying to my query. I am pleased to let you know that I have
 some experience of PHP, Javascript , CSS and MySQL.

Currently I'm exploring MediaWiki and working on a few bugs.


On Thu, May 9, 2013 at 8:17 AM, Sumana Harihareswara
wrote:

> On 05/03/2013 03:48 PM, Puneet Kaur wrote:
> > Hi all ,
> >
> > I know its late but still.
> >
> > I wished to let you all know that I have applied for the Wikidata
> Features
> > Project Idea in GSOC 2013.
> >
> > I have a bit of experience in website development and designing, but I am
> > not sure whether all of my present knowledge would be sufficient for the
> > project.
> >
> > I shall be exploring my hands on wikidata, the online knowledge base for
> > the rest of days.
> >
> > Do let me know if I am expected of anything else than that mentioned
> above.
> >
> >
> > Regards,
> > Puneet
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
> >
>
> Puneet, thanks for the email, but *linking* to your proposal would have
> been helpful. https://www.mediawiki.org/wiki/User:Puneet_kaur :-)
>
> Have you ever worked in PHP before? Have you worked on MediaWiki before?
> Have you started the steps in
> https://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker and
> potentially worked on a small bug suitable for novices?
> --
> 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] Feasibility question: Posting mailing list notifications to a wiki page

2013-05-09 Thread Guillaume Paumier
Hi,

There's currently a proposal on the English Wikipedia about creating a
"Developer's noticeboard" so that people can stay informed about
technical announcements outside of the noisy Village Pump/Technical:
https://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Developer.27s_Noticeboard

The main argument (as I understand it) is that existing venues (like
the wikitech-ambassadors mailing list, currently used for this
purpose) don't meet the needs of users who want to be notified on
their wiki, in their watchlist.

Rather than creating yet another (enwiki-only) venue for technical
announcements, I'd prefer to find a way to use the current venues, and
augment them to mitigate their limitations.

What I currently have in mind is a bot subscribed to the
wikitech-ambassadors list, that would post every first message of a
thread to the talk page of people who have signed up (like
https://meta.wikimedia.org/wiki/Global_message_delivery/Targets/Tech_ambassadors
) or to a noticeboard (that would then be mostly automated).

The bot would create a new section, using the email's subject line as
the section title, and its body as the message. It would ideally link
back to the gmane archive for that thread, so that users can read
follow-up messages there. Messages could be trimmed if they're too
long. The system could possibly also be used for other mailing lists
later.

My intuition is that this wouldn't be exceptionally hard to implement,
but I'd like a more informed opinion. Does anyone have experience with
a similar tool? Would someone be interested in giving it a try?

In the longer term, the Notifications system will hopefully end up
solving the issue in a better way, but if a quick bot hack can be a
good interim alternative, I think it's worth a shot.

--
Guillaume Paumier
Technical Communications Manager — Wikimedia Foundation
https://donate.wikimedia.org

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

Re: [Wikitech-l] automatic extraction of wikipedia entries

2013-05-09 Thread Pierre Jourlin

> You are invited to test my demonstration at :
> http://dev.termwatch.es/~jourlin/demo.php

Sorry for this omission :
id: master
pw: sitnosh




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

[Wikitech-l] automatic extraction of wikipedia entries

2013-05-09 Thread Pierre Jourlin
Hello,

I'm a computer science researcher in the university of Avignon, in France. I
recently developed a software that automatically and quickly extract from an
UTF-8 text all the (longest) terms that belongs to a large set of terms. 
The term extractor works as a server and I tested it successfully with a
thesaurus made of the page's titles of fr.wikipedia.org, en.wikipedia.org
and es.wikipedia.org, i.e. 9,387,079 distinct terms composed from 4,496,195
distinct words. 
You are invited to test my demonstration at :
http://dev.termwatch.es/~jourlin/demo.php
The source code can be found at Github (condition of use, redistribution,
modification under the terms of the GNU Public License V3):
https://github.com/jourlin/FELTS

I roughly guessed that it could be of some interest for the development of
Mediawiki but I would very much appreciate any feedback before I look
further into that question.

Best regards,

Pierre Jourlin.


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