date:20111107

User "NeilK" changed the status of MediaWiki.r100699.

Old Status: new
New Status: ok

User "NeilK" also posted a comment on MediaWiki.r100699.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100699#c25661
Commit summary:

(bug 31499) articlePathRegex (detection of external links within the same wiki) 
broken when wgServer is protocol-relative

Comment:

Evil, but it works.

Incidentally, mediawiki.Uri.js parses and creates protocol-relative URLs now. 
Not sure if it helps in this case.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r98432]: New comment added, and revision status changed

User "NeilK" changed the status of MediaWiki.r98432.

Old Status: new
New Status: ok

User "NeilK" also posted a comment on MediaWiki.r98432.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/98432#c25660
Commit summary:

WikiEditor: Fix bug where ext.wikiEditor would load and wrap the textarea even 
if the toolbar was disabled. This has been reported to me on IRC but I'm not 
aware of any bug report in BZ

Comment:

would have been easier to understand as !( a && b ), but marking okay anyway.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

On Mon, Nov 7, 2011 at 10:54 PM, Tim Starling  wrote:
> My recommendation is that you contact people who commit code to your
> extension, and request that they agree to license their contributions
> under a BSD-style license.

That would of course be the (please print out this form, sign it, scan
it, then email me a copy) sure-fire way of contribution agreements.
However if one hoped to make use of a service like the MW repo, this
seems like too much of a hassle and like Rob mentioned, you're then
better off just running your own show, elsewhere. And as you mention
with translators it becomes near-impossible.

> As I said before, I don't think a normal contributor agreement can be
> binding, because you don't control access to the repository. I also
> don't think your browse-wrap style contract will be binding on all
> contributors. In OTRS you wrote:

Agreed, like I mention above, short of getting a signed document,
these things aren't legally binding, so the question of it's even
worth having comes up pretty strongly. I've sent the question off to
OSI license-discuss, I'm hoping they'll approve the message for
discussion there so I can get some feedback on what more knowledgeable
people think about BSD and contributions from outside sources. They
may be able to say what we hope to hear "the BSD header is enough" or
what I fear "you need signed contrib agreements" or some middle ground
"here's some legal-lawyer speak that project X,Y,Z have used to
mitigate this problem".

> That's why I think that if you want to have a pure-BSD extension with
> solid legal footing, you should drop these headers from your source
I hope you don't mean the BSD license, and just meant the pseudo
contributor agreement license-amendment I was toying with.

But in the end, my particular situation is just one of 3 that I
mentioned could arise, with the other two being much more common. I
don't want this discussion to just focus on my particular struggle
with how to license my code, but on how MW might deal with more
general non GPL-only code.  Like say someone wanted to commit using
the Microsoft OSI-approved license, or some non-gpl-compatible OSI
license.  And of course the case of GPL/propriatery dual-licensing
arrangements.

Especially given how some people are doing some massive things with
extensions (like SMW) I don't see it as unrealistic that this will
come up, especially if building a healthy and strong extension
developer continues on it's current track.

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

[MediaWiki-CodeReview] [MediaWiki r102333]: Revision status changed

User "MaxSem" changed the status of MediaWiki.r102333.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102333
Commit summary:

Userinfo for Maik Merten (worked on cortado)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

2011-11-07 Thread Tim Starling

On 08/11/11 02:08, Olivier Beaton wrote:
> And here's where I currently stand with my own work. I'm no expert on
> licensing and my wording so far may not be great, but there seems to
> be some concern in BSD-like licenses that without such a clause in a
> shared-commit environment can lead to trouble. Zend Framework is
> BSD-3-Clause'd and has a contributor agreement to handle IP issues
> (and not for any dual-licensing goals).

My recommendation is that you contact people who commit code to your
extension, and request that they agree to license their contributions
under a BSD-style license.

If they do not agree to do this, then you can merge their changes out
of your fork on olivierbeaton.com. But knowing the MediaWiki
community, I doubt that that will ever happen.

Localisation commits may be slightly tricky. At
 it says

"Derivative works may also be licensed under the licenses of the
respective Free and Open Source projects the translations have been or
will be added to."

So in principle it will be fine, but if you wanted to obtain an
assurance from every individual translator as to whether have truly
agreed to that licensing policy, you would be facing a challenge. If
worst comes to worst, you can always distribute a pure-BSD fork which
is stripped of localisations derived from translatewiki.net.

As I said before, I don't think a normal contributor agreement can be
binding, because you don't control access to the repository. I also
don't think your browse-wrap style contract will be binding on all
contributors. In OTRS you wrote:

/*
 By comitting against this file you retain copyright for your
contributions and grant
them to Olivier Finlay Beaton under the same BSD-2-Clause license
(attribution).
*/

You can't make a contract with someone in such a passive way, you have
to bring the terms to their attention somehow and extract their active
agreement. Also, as with the copyright assignment, there's a lack of
consideration. The committer can explicitly refuse to enter the
contract and then commit anyway.

That's why I think that if you want to have a pure-BSD extension with
solid legal footing, you should drop these headers from your source
files and rely on direct email contact with the extension
contributors. That would also have the advantage of being less
controversial.

-- Tim Starling

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

Re: [Wikitech-l] wikipedia lacks a "share' button

2011-11-07 Thread shi zhao

Also see share gadget in chinese wikipedia:

https://zh.wikipedia.org/wiki/MediaWiki:Gadget-shareTool.js

Chinese wikipedia: http://zh.wikipedia.org/
My blog: http://shizhao.org
twitter: https://twitter.com/shizhao

[[zh:User:Shizhao]]



2011/11/8 Tomasz Finc 

> Which is why it should be a personal choice of wether it shows up or
> not. To me the simplest way to fix this is to make sharing through
> something like facebook an opt in account level feature.
>
> This would mean that you opt in to facebook sharing fully knowing that
> your adhering to their data policies. Some people are clearly ok with
> this and and we should honor their request but not at the cost of
> other users privacy.
>
> That way anyone who wants it can knowingly opt in and get it while
> everyone else wont see it if they don't want to.
>
> --tomasz
>
> On Fri, Nov 4, 2011 at 3:57 PM, Platonides  wrote:
> > jida...@jidanni.org wrote:
> >> So 50% of users want a share button.
> >> That's plenty.
> >> Some features only need 5% to make them candidates for implementation.
> >> So one would hope it would get implemented one way or the other.
> >
> > You shouldn't just take into account how many people want it, but also
> > how many people want to not have it...
> >
> >
> > ___
> > 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] [Ticket#2011091710005702] SVN Extension Access

2011-11-07 Thread Daniel Friesen

On Mon, 07 Nov 2011 09:10:09 -0700, Olivier Beaton  
 wrote:
> And to those who will say "git will fix everything" I should point out
> nothing in this thread is fixed by having easier access restrictions
> (ie, restricting access from all of core, to all extensions, to a
> specific extension -- the last which git solves), and instead tries to
> look at the question of "do we want this code in the community
> repository?"
>
> - Olivier
Small side note, better access separation isn't the only thing the git  
migration does. The plan seams to be to use a gated trunk model. One with  
gerrit such that anyone can have a labs/git account, using that account  
you can push a commit and it shows up a changeset in gerrit, from there  
once it's reviewed it makes it's way into trunk.
Under that model of committing to trunk everyone is pretty much equal.  
Whether you're a long-time committer or you just got an account a second  
ago by filling out a form and getting one automatically anyone can get a  
change in for review and changes are reviewed individually by developers  
rather than forcing non-developers to deal with reviewing a person based  
on their past code.

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

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

[MediaWiki-CodeReview] [MediaWiki r102073]: New comment added

User "Aaron Schulz" posted a comment on MediaWiki.r102073.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102073#c25659
Commit summary:

* Added File::normalizeTitle() function and used it to consolidate file title 
validity checks and sanitation. (bug 32195)
* Broke a few long lines.

Comment:

It looks unholy.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] wikipedia lacks a "share' button

2011-11-07 Thread Tomasz Finc

Which is why it should be a personal choice of wether it shows up or
not. To me the simplest way to fix this is to make sharing through
something like facebook an opt in account level feature.

This would mean that you opt in to facebook sharing fully knowing that
your adhering to their data policies. Some people are clearly ok with
this and and we should honor their request but not at the cost of
other users privacy.

That way anyone who wants it can knowingly opt in and get it while
everyone else wont see it if they don't want to.

--tomasz

On Fri, Nov 4, 2011 at 3:57 PM, Platonides  wrote:
> jida...@jidanni.org wrote:
>> So 50% of users want a share button.
>> That's plenty.
>> Some features only need 5% to make them candidates for implementation.
>> So one would hope it would get implemented one way or the other.
>
> You shouldn't just take into account how many people want it, but also
> how many people want to not have it...
>
>
> ___
> 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] License exceptions in Wikimedia's repo

What do I gain by not using gpl? Commercial use and forking under a license
of your choice. The only thing that concerns me using bsd is how to accept
contributions that im not merging in safely. Is zend framework concern with
bsd and their use of a contrib agreement ?

My employer asked me to make modifications to mw for their use, i chose
instead to spend my free time so i can share them with others. I cant use
gpl even if i wanted to.
On Nov 7, 2011 7:31 PM, "Mark A. Hershberger" 
wrote:

>
> Olivier Beaton  writes:
>
> >> Could you elaborate on that?
> >
> > Given that I wasn't using the GPL, I was concerned that anyone
> > committing against my code would do so under "all rights reserved" and
> > would effectively be forking my code from the point of their revision.
> > I wanted to make sure the code stayed under my BSD-2-Clause license.
>
> I'm pretty confused by this whole situation.
>
> IANAL, but if you add restrictions such that you require modifications
> to be under the BSD-2-Clause license, then it seems like you have
> re-invented dual-licensing with the GPL license without any real
> benefit.  If that is the case, I am not in favor of adding
> yet-another-licensing-scheme to our repository.  But I could be swayed,
> given the right argument.
>
> What is the pragmatic benefit of your proposed license?
>
> Mark.
>
> ___
> 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] MediaWiki handout material

2011-11-07 Thread Sumana Harihareswara

On 11/07/2011 08:41 PM, Tisza Gergő wrote:
> Hi all,
> 
> I am a member of Wikimedia Hungary, which will have a stand at the Hungarian 
> Free Software Conference this weekend. I thought that would be a good 
> oppurtinity to raise awareness for MediaWiki. Do you know of leaflets or 
> other 
> handout materials about SMW which I could translate to help with that? Or any 
> source material to compose something similar from? Testimonials, comparisons, 
> statistics, feature sets etc.
> 
> thanks
> Gergő

Gergő, thanks for your note!  Here's a leaflet you can print and give
out to encourage people to contribute to MediaWiki:

https://www.mediawiki.org/wiki/File:MediaWiki_flyer_20110725-1.pdf
Editable version:
https://www.mediawiki.org/wiki/File:MediaWiki_flyer_20110725-1.svg

A longer list of things tech volunteers can do --
https://commons.wikimedia.org/wiki/File:Top_ten_things_technical_volunteers.pdf

And here are some testimonials:

https://www.mediawiki.org/wiki/MediaWiki_testimonials

And some logos:

https://commons.wikimedia.org/wiki/Category:MediaWiki_logos

Hope this helps!

best,
Sumana


-- 
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

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

[Wikitech-l] MediaWiki handout material

2011-11-07 Thread Tisza Gergő

Hi all,

I am a member of Wikimedia Hungary, which will have a stand at the Hungarian 
Free Software Conference this weekend. I thought that would be a good 
oppurtinity to raise awareness for MediaWiki. Do you know of leaflets or other 
handout materials about SMW which I could translate to help with that? Or any 
source material to compose something similar from? Testimonials, comparisons, 
statistics, feature sets etc.

thanks
Gergő


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

[Wikitech-l] New committer

2011-11-07 Thread Tim Starling

Karima Rafes (krafes): LinkedWiki


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

Re: [Wikitech-l] License exceptions in Wikimedia's repo

Olivier Beaton  writes:

>> Could you elaborate on that?
>
> Given that I wasn't using the GPL, I was concerned that anyone
> committing against my code would do so under "all rights reserved" and
> would effectively be forking my code from the point of their revision.
> I wanted to make sure the code stayed under my BSD-2-Clause license.

I'm pretty confused by this whole situation.

IANAL, but if you add restrictions such that you require modifications
to be under the BSD-2-Clause license, then it seems like you have
re-invented dual-licensing with the GPL license without any real
benefit.  If that is the case, I am not in favor of adding
yet-another-licensing-scheme to our repository.  But I could be swayed,
given the right argument.

What is the pragmatic benefit of your proposed license?

Mark.

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

[MediaWiki-CodeReview] [MediaWiki r102349]: Revision status changed

User "Aaron Schulz" changed the status of MediaWiki.r102349.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102349
Commit summary:

Project status and future architecture.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102313]: Revision status changed

User "Awjrichards" changed the status of MediaWiki.r102313.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102313
Commit summary:

CA form should use CA, not US

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[Wikitech-l] TestSwarm plugin for Jenkins

2011-11-07 Thread Krinkle

Hi all,

So as should be known by now we're going with QUnit for writing and running
unit test of JavaScript and PHPUnit for writing and running unit test for
our PHP code base. One can manually run both of these locally without
problems (phpunit from CLI and QUnit test from the browser at
[mw]/tests/qunit/index.php [1]).

As automated continuous integration we're letting Jenkins update mediawiki,
run the tests and keep track of everything (including notification to IRC).

Although it's theoretically possible to let Jenkins run QUnit tests
(node.js from shell running  synchronously), what we really want is
throwing all javascript unit tests onto our swarm of actual browsers. For
that we use TestSwarm, but it's downside is that it's not as cool as
Jenkins in providing statistics and insight into the state of our code.

The jQuery Testing team found a cool solution. Hooking up TestSwarm into
Jenkins.

See their instance at http://swarm.jquery.org:8080/#jenkins

Now one thing that might throw you off is the 'running build'. Jenkins is
not controlling the runs, as it shouldn't.
TestSwarm is controlling this through the swarm. Jenkins is merely
aggregating results, which, depending on the definition of "build ready"
can take a long time if one of the required browsers isn't connected to the
swarm. We will probably have to find a way to make this look better and
have statistics available even when not every browser is connected so that
we don't have to wait for "build ready", which has a different meaning when
working with multiple clients and 100s of asynchronous runs.

But overall it's very nice, I think we should take the same approach for
MediaWIki. Instead of trying to make TestSwarm do something it's not
designed for, let TestSwarm do what it's good at, and let Jenkins do what
it is good at.

More info:
* Project planning page by the jQuery Testing team:
http://jquerytesting.pbworks.com/w/page/43991777/TestSwarm-Jenkins-Integration
* Fork it on Github: https://github.com/appendto/jenkins-testswarm
* The jQuery Testing team

--
Krinkle

PS: Before we can use this though there are many things to do first on
integration.mediawiki.org; Such as installing TestSwarm, merging JSTesting
branch into trunk, setting up and testing the TestSwarmMwFetcher.. Just
wanted to get this idea out there before someone might waste time trying to
do the same.

[1] Soon to be /wiki/Special:JavaScriptTest/qunit :) (see
/branches/JSTesting/)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[MediaWiki-CodeReview] [MediaWiki r102347]: Revision status changed

User "Krinkle" changed the status of MediaWiki.r102347.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102347
Commit summary:

htmlescape user-provided HTTP_ACCEPT_LANGUAGE (although unlikely to cause any 
harm)
Follow-up r102205

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102205]: New comment added

User "Platonides" posted a comment on MediaWiki.r102205.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102205#c25658
Commit summary:

[TsIntuition] Minor fixes in acceptableLanguages()
* Adding an example of the static utility function to demo/demo6
* Moving the function out of the TsIntuition class into TsIntuitionUtil where 
the other static utility functions are, renaming to getAcceptableLanguages
* Improving documentation/variable naming a little bit
* Whitespace / curly braces fixes
* Although I'm not 100% sure about this, I've added a FIXME about the q-val 
defaulting to 1. It needs a look-ahead technique to be more solid, right now 
low-level accept-languages are getting too high. Example:
-- code
getAcceptableLanguages: ( 'nl-be,nl;q=0.7,en-us,en;q=0.3' ):
array(4) {
  ["nl-be"]=>
  string(1) "1" // should be 0.7
  ["en-us"]=>
  string(1) "1" // should be 0.3
  ["nl"]=>
  string(3) "0.7"
  ["en"]=>
  string(3) "0.3"
}
-- /code
See demo6 for more this in action

* Follows-up r100234

Comment:

The relevant standard I followed is rfc 2616. The most relevant piece 

(from section 14.4) would be:
 Each language-range MAY be given an associated quality value 
 which represents an estimate of the user's preference for the 
 languages specified by that range. The quality value defaults to "q=1".

If you find the standard to imply otherwise, please share.



Now to the Firefox behavior: I couldn't reproduce it.

When I add nl, en-us and en in Firefox languages, I get
 nl,en-us;q=0.7,en;q=0.3
which is consistent with what I expected.

Ordering, 'nl, en-us, en' it's
 nl,en-us;q=0.7,en;q=0.3

Setting also nl-be:
 nl-be,nl;q=0.8,en-us;q=0.5,en;q=0.3

How did you get "nl-be,nl;q=0.7,en-us,en;q=0.3" from Firefox interface?


I looked for a Firefox bug like that, but didn't find it.

Yet, there are some interesting ones like 
[https://bugzilla.mozilla.org/show_bug.cgi?id=55800 55800] or 

[https://bugzilla.mozilla.org/show_bug.cgi?id=58034 58034: Accept-Language 
header needs q values] which 

supports my view in the opening comment:
 You can change the priority of the languages within the preferences, but no q
 values are attached to each language. Thus, true content negotiators such as
 mod_negotiation in Apache view all languages as being preferred equally, as
 according to HTTP/1.1 (IE properly adds q values to the languages)

That bug follows to the patch adding q-values, with 
[https://bugzilla.mozilla.org/show_bug.cgi?id=58034#c7 comment 7] explaining

firefox algorithm for q-value assignation:
 1 is divided amongst the languages present. For
 example, if you have three languages, the first gets a q of 1.000, the second
 gets 0.667, the third gets 0.333.


I don't know how that unqvalued 'en-us' arrived to your Accept-Language header.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r99369]: New comment added

User "Dantman" posted a comment on MediaWiki.r99369.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99369#c25657
Commit summary:

Fix up makeLinkItem and makeLink:
- Don't explicitly name attributes to use (fixes bug on language_links in 1.18)
- Allow makeLink to accept options specifying how to wrap links and text

Comment:

This was something for the BaseTemplate skin stuff I introduced in in 1.18.

The addition of link-fallback, link-class, and text-wrapper is somewhat minor 
and not used anywhere by default but it's something I really should have 
accounted for in the original BaseTemplate::makeLink code that I didn't at the 
time, and later realized when I attempted to use my own BaseTemplate code 
inside of a client project that needed it in order for the design to work.
It's a minor feature but without it the BaseTemplate stuff isn't really 
complete.

Also in here is a fix for a regression caused by the BaseTemplate code. The 
language_urls had a title on them pre-1.18 but because I had this code 
white-listing attributes the title="" was being stripped out of stuff in the 
language box in skins updated to use makeListItem. On a suggestion from another 
user I switched the code to blacklist stuff actually used rather than only 
allow a limited subset of attributes.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

2011-11-07 Thread Platonides

Olivier Beaton wrote:
> On Mon, Nov 7, 2011 at 1:15 PM, Erik Moeller  wrote:
>> Could you elaborate on that?
> 
> Given that I wasn't using the GPL, I was concerned that anyone
> committing against my code would do so under "all rights reserved" and
> would effectively be forking my code from the point of their revision.
> I wanted to make sure the code stayed under my BSD-2-Clause license.

Why did you think so?

I'm of the same opinion as bawolff:
> My understanding is we allow people to commit extensions under
> whatever OSI approved license strikes their fancy, and that if you
> commit to someone else's extension, then you also release your commit
> under that license. This always struck me as common sense...

If you edit a file with a header "This is under BSD license", and not
changing it, or otherwise conflicting with that statement, I consider
you're releasing that commit under the BSD license.
Now, it would certainly be possible that someone did a commit saying
"This is my own copyright, and nobody is allowed to make derivatives of
this", but
(a) I expect that would be immediatly reverted (what is doing such
unfree code on our svn, and further /restricting/ the previous one?)
(b) It's silly to commit it to a public repo if you want to keep it for
your own.

If someone does a magic improvement to it, it may want to keep its
changes for himself and not release them. Note that GPL doesn't prevent
that, either (only if there's redistribution).
IMHO, such person would do a better job providing it upstream, first as
a good netizenship (give back to people which gave you the system), and
second because that would allow for being better maintained, and remove
the pain of merging each time (so it's also a good thing from an
egoistic perspective).

Olivier proposal
> My first stab at this was to use a contributor agreement that
> contained a copyright assignment, as people do for dual-licensing with
> GPL code. A little bit later I found the Zend Framework license, which
> uses a BSD-3-Clause and a contributor agreement (which forces
> contributions to give ZF a license to the code in the contribution,
> not copyright assignment) and I quickly changed to suit. Rob seems to
> think this may still be unnecessary, and I've sent a mail to the OSI
> license-discuss mailing to list for clarification on that matter.

further explained by Tim:
> He wanted to have a contributor agreement which required anyone who
> changed the file in Subversion to assign copyright to him. The content
> was all under a BSD-style license and anyone could modify it, so the
> contract would have to have the form "if you agree to assign
> copyright, I will agree to allow you to commit to this file".
> 
> This kind of agreement is quite common in certain circles, but for it
> to work, the person who you're making the contract with has to be able
> to restrict write access to the source code repository. Since Olivier
> wasn't going to be able to restrict commit access himself, and we
> weren't going to do it for him, the contributor agreement didn't make
> sense.

I'm not sure if Olivier got confused with licenses, or is it just me who
got confused with Olivier reasons.
Using a BSD license with an extra same-license clause it's like making
CC-BY a CC-BY-SA. You can do it, but then CC-BY isn't the best
description / you may have chosen the wrong license.
There are some differences, as that wouldn't apply to users but only
upstream.
I find natural that he wants to keep the extension with the original
license, and the sensible thing to do among us is to keep the license
chosen by the original author.
Moreover, a contribution able to push a license change would need to
make a 'substantial' change, or might qualify as PD.

So going through a copyright assignment to the extension author looks
like an over-complication to me.
Each community has its own ways to do thing. That may be appropiate for
a community strict on non-SA free licenses where each module is tightly
handled by a owner, but I don't think it would work for us.

> But the discussion as I set it out in my previous email with the 3
> questions are much more general then my own particular case, and I
> think the community would benefit from consensus on how applications
> in each case should be handled in the future.
> 
> Q1. Should WMF allow Dual-Licensed extensions in the MediaWiki repo?

Yes.

> Q2. Should people using any OSI approved license without modification
> be able to use the MediaWiki repo?

Yes.

> Q3. Should people who add a clause to their license that all
> contributions are to be made under the same license be turned away?

That's a greyer area due to the "Are extensions linked?" debate, as such
license doesn't seem GPL-compatible. Still, it may be better to have it
with a license warning than not having it in the repo. Authors of such
extensions should be encouraged to dual-license it with a GPL-compatible
license.

If instead of a MediaWiki extension, it's an in

[MediaWiki-CodeReview] [MediaWiki r99092]: New comment added

User "Krinkle" posted a comment on MediaWiki.r99092.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99092#c25656
Commit summary:

(bug 31420) Fix weird tablesorter bug where headers spanning multiple rows 
would get screwed up. Thanks to TheDJ for essentially telling me exactly how to 
fix this, he was spot on.

Comment:

It is already tagged as 1.18, it is scheduled to be applied to 1.18. It 
apparently didn't get into the first beta but unless a different decision is 
made this revision will make it into the second beta or eventually the stable 
release.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r99092]: New comment added

User "G.Hagedorn" posted a comment on MediaWiki.r99092.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99092#c25655
Commit summary:

(bug 31420) Fix weird tablesorter bug where headers spanning multiple rows 
would get screwed up. Thanks to TheDJ for essentially telling me exactly how to 
fix this, he was spot on.

Comment:

I think we may have this bug. It is applied to 1.18wmf1, but left out of 1.18 
beta release (because of follow-up?). Please submit either this or the 
follow-up r101420.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r101811]: Revision status changed

User "Aaron Schulz" changed the status of MediaWiki.r101811.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101811
Commit summary:

prefix i18n msg with "vipsscaler-"

also added some missing translations and the qqq messages.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r101813]: Revision status changed

User "Aaron Schulz" changed the status of MediaWiki.r101813.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101813
Commit summary:

add a nice title to the special page

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r101976]: Revision status changed

User "^demon" changed the status of MediaWiki.r101976.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101976
Commit summary:

* fixed ipblocks.ipb_by_text field, removed default blank not null (fixed 
install&update)
* fixed Block->insert; ipblocks.ipb_id is autoincrement field (should use 
sequences for compatibility)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r101968]: Revision status changed

User "^demon" changed the status of MediaWiki.r101968.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101968
Commit summary:

* fixed a typo in oracle/tables.sql
* readded the sha1 fields (installer & upgrader)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r100716]: Revision status changed

User "^demon" changed the status of MediaWiki.r100716.

Old Status: new
New Status: resolved

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100716
Commit summary:

Added temporary LocalFilePurgeThumbnails hook for bug 27641

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r101224]: Revision status changed

User "^demon" changed the status of MediaWiki.r101224.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101224
Commit summary:

FU r100716:
* Pass the File object in LocalFilePurgeThumbnails so handlers can use the 
getRel() functions and such
* Also added the hook to hooks.txt, as this could be useful for other caches or 
things in thumb_handler.php

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r101389]: New comment added

User "Preilly" posted a comment on MediaWiki.r101389.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101389#c25654
Commit summary:

mft r101388

Comment:

It isn't now — that was a mistake.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r99369]: New comment added

User "Hashar" posted a comment on MediaWiki.r99369.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99369#c25653
Commit summary:

Fix up makeLinkItem and makeLink:
- Don't explicitly name attributes to use (fixes bug on language_links in 1.18)
- Allow makeLink to accept options specifying how to wrap links and text

Comment:

removing this from 1.18. It is too late to have this new feature reviewed 
properly. Postponing to 1.19.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r100854]: New comment added

User "Preilly" posted a comment on MediaWiki.r100854.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100854#c25652
Commit summary:

mft r100851

Comment:

It isn't now... that was a mistake.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r101389]: New comment added

User "^demon" posted a comment on MediaWiki.r101389.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101389#c25651
Commit summary:

mft r101388

Comment:

Why is a deployment merge tagged for 1.18?

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] [Ticket#2011091710005702] SVN Extension Access

2011-11-07 Thread Platonides

Olivier Beaton wrote:
> In my case a lot of the back-and-forth seemed centered around
> licensing issues, which can be fairly complex (if you take a look at
> the robla licensing thread). I tried twice to approach the only point
> of contact I had (Sumana) to start a discussion about this informally,
> but was met with what I felt was a "sorry the council in session
> behind closed doors, please wait until they make their decision" or at
> the least "I can't really talk about this without everyone being
> here". Again this is not an attack on Sumana personally, but on the
> process.
> 
> I would of loved it if she had been empowered to say something about
> what the issues being discussed were, and be able to further
> facilitate communication between the people raising the issues and
> myself. I understand sometimes this isn't possible, but given how
> active I am in IRC and that I (had) a standing rapport with Sumana and
> other developers, this didn't seem out of the question. Instead each
> time I waited a week only to learn some new issue was raised. I never
> knew who these people raising these issues were (so that I wouldn't
> harass them? I admit this can be a a real issue).

In this case, as you were active in irc, it indeed seems that it would
have been faster if you were said "We are going to discuss it at
#commit-cabal on the  midnight of Friday 13. Can you make it at
#sacrifices while we discuss?" That way, you could have been asked the
questions on the fly instead of such slow back-and-forth.



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

[MediaWiki-CodeReview] [MediaWiki r100854]: New comment added

User "^demon" posted a comment on MediaWiki.r100854.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100854#c25650
Commit summary:

mft r100851

Comment:

Why is a deployment merge tagged as 1.18?

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102335]: Revision status changed

User "Hashar" changed the status of MediaWiki.r102335.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102335
Commit summary:

Follow-up r102334: odd that this minus sign (yes, copied from a diff) was 
actually harmless.  Also explicitly define a variable that would otherwise be 
lazily initialised to zero but about which my IDE complains.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102334]: New comment added

User "Hashar" posted a comment on MediaWiki.r102334.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102334#c25649
Commit summary:

(bug 31502) (follow-up r84718) Restore ToC to Special:EditWatchlist if there is 
more than one namespace and more than 30 titles total (also resolves the 
commented TODO in the pre-r84718 code).

Comment:

seems to fix a regression


___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102080]: Revision status changed

User "^demon" changed the status of MediaWiki.r102080.

Old Status: new
New Status: deferred

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102080
Commit summary:

[FLVHandler] Update command line to work with recent FFmpeg versions

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r101229]: Revision status changed

User "^demon" changed the status of MediaWiki.r101229.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101229
Commit summary:

Disable proxy for local URLs instead of using a local proxy (which might not 
always exist). In r61357 a comment "Not sure this makes any sense." was 
removed. Indeed, that comment seems to have been right :)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r99898]: Revision status changed

User "^demon" changed the status of MediaWiki.r99898.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99898
Commit summary:

* restored category page (some references to Title object were missing)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r101285]: Revision status changed

User "^demon" changed the status of MediaWiki.r101285.

Old Status: new
New Status: deferred

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101285
Commit summary:

Simplified subobject management by using property "_SOBJ" (Has subobject) to 
associate the data.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r84718]: New comment added, and revision status changed

User "Happy-melon" changed the status of MediaWiki.r84718.

Old Status: fixme
New Status: new

User "Happy-melon" also posted a comment on MediaWiki.r84718.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84718#c25648
Commit summary:

Move WatchlistEditor.php to /specials since inside it is essentially a complete 
special page.  Make it subclass SpecialPage and do all the usual stuff.  
Rewrite it to use HTMLForm and other exciting things, and give it a good 
general clean up.

Comment:

Fixed in r102334.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r100677]: Revision status changed

User "Amire80" changed the status of MediaWiki.r100677.

Old Status: new
New Status: resolved

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100677
Commit summary:

Refactor the setup code with seperate mathods for loading fonts for lang attr 
and style definition.
Use addFont method to avoid duplication of css.
More comments.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102326]: Revision status changed

User "^demon" changed the status of MediaWiki.r102326.

Old Status: new
New Status: deferred

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102326
Commit summary:

Follow-up to r93180 - fixed handling if mb_detect_encoding() function does not 
exist

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] 1.18 tarball ... making it happen

Daniel Barrett  writes:

> Please consider https://bugzilla.wikimedia.org/show_bug.cgi?id=32241
> (which I just discovered and reported) for 1.18.0.
>
> It causes your first WikiEditor operation (e.g., clicking the Bold
> button) to fail if you are running Windows 7.

Done.

Mark.

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

Re: [Wikitech-l] 1.18 tarball ... making it happen

Chad  writes:

> I see at least 7 revisions that don't block the 1.18 general release.
> Anything to do with an extension that isn't bundled isn't a blocker.

Right.  Thanks for pointing that out.

I've removed the 1.18 tag from those revisions and that brought the
total down to 29.  I left r97175 in there because it includes
modifications (a couple of hooks) to core.

Thanks,

Mark.

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

Re: [Wikitech-l] 1.18 tarball ... making it happen

2011-11-07 Thread Daniel Barrett

Please consider https://bugzilla.wikimedia.org/show_bug.cgi?id=32241 (which I 
just discovered and reported) for 1.18.0. 

It causes your first WikiEditor operation (e.g., clicking the Bold button) to 
fail if you are running Windows 7.
 
DanB
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] page view stats redux

2011-11-07 Thread Domas Mituzas

Hi!

> I had thought to do a daily update.  If it turns out that hourly updates
> are indeed useful, I'll set that up.  I don't know of anyone else that
> has a current mirror.

Yeh, don't believe anything I say, wait for someone on mailing list to tell you 
the same to make conclusions. 

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

[MediaWiki-CodeReview] [MediaWiki r102306]: Revision status changed

User "Aaron Schulz" changed the status of MediaWiki.r102306.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102306
Commit summary:

* Added specific page header when showing "search deleted pages" form
* Throw an exception directly instead of calling 
OutputPage::permissionRequired()
* Removed unreachable code paths
* Show nicer error messages when undeletion could not be executed
* Pass the subpage parameter to loadRequest() and define $mTarget and 
$mTargetObj there

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

2011-11-07 Thread Erik Moeller

On Mon, Nov 7, 2011 at 10:37 AM, Olivier Beaton
 wrote:

> My first stab at this was to use a contributor agreement that
> contained a copyright assignment, as people do for dual-licensing with
> GPL code. A little bit later I found the Zend Framework license, which
> uses a BSD-3-Clause and a contributor agreement (which forces
> contributions to give ZF a license to the code in the contribution,
> not copyright assignment) and I quickly changed to suit. Rob seems to
> think this may still be unnecessary, and I've sent a mail to the OSI
> license-discuss mailing to list for clarification on that matter.

Yeah, I think Rob's right on that, but would be interested to see what
you find out.

I personally don't philosophically object to having extensions in the
repo that require dual-licensing of all future contributions under some
set of OSI-approved licenses, without any kind of copyright assignment.
But I can see that it might be a pain to maintain such a regime in
practice.
-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

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

Re: [Wikitech-l] 1.18 tarball ... making it happen

2011-11-07 Thread Chad

On Mon, Nov 7, 2011 at 2:14 PM, Mark A. Hershberger
 wrote:
> == Reviewing all outstanding revisions ==
>
> http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/1.18?status=new
>
> The above link currently points to 35 revisions that need to be reviewed
> before we can ship a 1.18 tarball.  If I can get 7 reviewers to review
> one revision every day, we'll be done on Friday.
>

I see at least 7 revisions that don't block the 1.18 general release.
Anything to do with an extension that isn't bundled isn't a blocker.

-Chad

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

[MediaWiki-CodeReview] [MediaWiki r102307]: Revision status changed

User "Awjrichards" changed the status of MediaWiki.r102307.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102307
Commit summary:

using currency_code instead of currency since this is what DonationData is 
expecting

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102308]: Revision status changed

User "Awjrichards" changed the status of MediaWiki.r102308.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102308
Commit summary:

Switching out appeal and appeal title as well as setting the correct default

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102171]: Revision status changed

User "SVG" changed the status of MediaWiki.r102171.

Old Status: old
New Status: new

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102171
Commit summary:

Adding German message

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102171]: Revision status changed

User "SVG" changed the status of MediaWiki.r102171.

Old Status: reverted
New Status: old

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102171
Commit summary:

Adding German message

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102171]: Revision status changed

User "SVG" changed the status of MediaWiki.r102171.

Old Status: deferred
New Status: reverted

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102171
Commit summary:

Adding German message

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r100224]: Revision status changed

User "SVG" changed the status of MediaWiki.r100224.

Old Status: new
New Status: deferred

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100224
Commit summary:

Rename GlobalUserGroups.i18n.extras.php to GlobalUserGroups.i18n.groups.php

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[Wikitech-l] 1.18 tarball ... making it happen

We're getting really close making a 1.18 tarball happen. My hope is to
have it released in two weeks at most. How realistic is that?

== Fixing the 1.18 milestone bugs ==

https://bugzilla.wikimedia.org/buglist.cgi?resolution=---&target_milestone=1.18%20tarball%20release
http://hexm.de/97 (if the above URL wraps unusably).

There are three bugs here:

https://bugzilla.wikimedia.org/31060 -- [Regression] Sortable tables:
"unsortable" should also work for rows outside the table heading

https://bugzilla.wikimedia.org/31511 -- Unable to add/remove buttons
from (classic) toolbar from a gadget after MW update

https://bugzilla.wikimedia.org/31682 -- MW1.18 broke Edittools for
Special:Upload

That's down from 8 that were on the list last week. Now, granted, a
couple were removed from the from the milestone and are still open. But
in the meantime, we still fixed a few.

== Reviewing all outstanding revisions ==

http://www.mediawiki.org/wiki/Special:Code/MediaWiki/tag/1.18?status=new

The above link currently points to 35 revisions that need to be reviewed
before we can ship a 1.18 tarball. If I can get 7 reviewers to review
one revision every day, we'll be done on Friday.

== Fixing the FIXMEs ==

http://www.mediawiki.org/wiki/MediaWiki_roadmap/1.18/Revision_report

There are two FIXME'd revisions left. The committers (Krinkle and
Happy-Melon) are aware of them, but anyone can fix the problems if they
are motivated.

I think getting a 1.18 tarball out in two weeks is completely do-able.
Let's make it happen!

Mark.

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

Re: [Wikitech-l] page view stats redux

2011-11-07 Thread Ariel T. Glenn

Στις 07-11-2011, ημέρα Δευ, και ώρα 18:41 +, ο/η Sean Timm έγραψε:
> Ariel T. Glenn  wikimedia.org> writes:
> 
> > 
> > I think we finally have a complete copy from December 2007 through
> > August 2011 of the pageview stats scrounged from various sources, now
> > available on our dumps server.  
> > 
> > See http://dumps.wikimedia.org/other/pagecounts-raw/
> > 
> > Ariel
> > 
> 
> 
> This is very cool.  Thanks for the work, Ariel.  I'm interested to look at the
> historical data.
> 
> It appears that page view data is pushed to dumps.wikimedia.org daily.  
> dammit.lt
> used to push page view stats hourly, but it appears to be down now.  Are 
> hourly
> pushes still available somewhere?
> 
> Thanks,
> Sean

I had thought to do a daily update.  If it turns out that hourly updates
are indeed useful, I'll set that up.  I don't know of anyone else that
has a current mirror.

Ariel




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

Re: [Wikitech-l] page view stats redux

2011-11-07 Thread Sean Timm

Ariel T. Glenn  wikimedia.org> writes:

> 
> I think we finally have a complete copy from December 2007 through
> August 2011 of the pageview stats scrounged from various sources, now
> available on our dumps server.  
> 
> See http://dumps.wikimedia.org/other/pagecounts-raw/
> 
> Ariel
> 

This is very cool.  Thanks for the work, Ariel.  I'm interested to look at the
historical data.

It appears that page view data is pushed to dumps.wikimedia.org daily.  
dammit.lt
used to push page view stats hourly, but it appears to be down now.  Are hourly
pushes still available somewhere?

Thanks,
Sean

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

Re: [Wikitech-l] License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

On Mon, Nov 7, 2011 at 1:15 PM, Erik Moeller  wrote:
> Could you elaborate on that?

Given that I wasn't using the GPL, I was concerned that anyone
committing against my code would do so under "all rights reserved" and
would effectively be forking my code from the point of their revision.
I wanted to make sure the code stayed under my BSD-2-Clause license.

My first stab at this was to use a contributor agreement that
contained a copyright assignment, as people do for dual-licensing with
GPL code. A little bit later I found the Zend Framework license, which
uses a BSD-3-Clause and a contributor agreement (which forces
contributions to give ZF a license to the code in the contribution,
not copyright assignment) and I quickly changed to suit. Rob seems to
think this may still be unnecessary, and I've sent a mail to the OSI
license-discuss mailing to list for clarification on that matter.

But the discussion as I set it out in my previous email with the 3
questions are much more general then my own particular case, and I
think the community would benefit from consensus on how applications
in each case should be handled in the future.

Q1. Should WMF allow Dual-Licensed extensions in the MediaWiki repo?

Q2. Should people using any OSI approved license without modification
be able to use the MediaWiki repo?

Q3. Should people who add a clause to their license that all
contributions are to be made under the same license be turned away?

I gave my thoughts one each question in my previous email. My original
request would of been answered by a clear stance on Q1. My current
code would have a clear answer given Q3. But I doubt I will be the
last to try any of the 3.

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

Re: [Wikitech-l] License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

2011-11-07 Thread bawolff

> Message: 10
> Date: Mon, 7 Nov 2011 15:40:58 +
> From: David Gerard 
> Subject: Re: [Wikitech-l] License exceptions in Wikimedia's repo (was
>       Re: SVN Extension Access)
> To: Wikimedia developers 
> Message-ID:
>       
> Content-Type: text/plain; charset=UTF-8
>
> On 7 November 2011 15:08, Olivier Beaton  wrote:
>
> > To make it clear, copyright assignments (what I had in my original
> > request) are common in the FOSS community, as you pointed out you
> > talked about them yourself on your blog and wmf talked about having
>
>
> Copyright assignments are inherently harmful, as their only use is so
> that the assigned-to body can defect on the implicit covenant of open
> source: that is, so it can take people's contributions private.
>
> The FSF continues to use them, on the theory that this gives greater
> legal protection. While the FSF is quite unlikely to defect (it's
> spent twenty-five years behaving as a consistent actor), its legal
> theory appears unnecessary (neither the Linux kernel nor BusyBox use
> copyright assignments, but both have been spectacularly successful in
> pursuing GPL violations) and its continued use makes people think
> they're a good idea.
>
> For an example of defection, see Oracle taking MySQL open-core.
>
> Copyright assignments are harmful. They are not some sort of standard
> thing in open source. They would be harmful to MediaWiki.
>
>
> - d.


You don't need to go for ideological reasons to go against copyright
assignments to individual extension authors. It's simply impractical
in the MW repo where many people make batch maintenance commits to
expect all of those people to assign you their copyright (imho).

My understanding is we allow people to commit extensions under
whatever OSI approved license strikes their fancy, and that if you
commit to someone else's extension, then you also release your commit
under that license. This always struck me as common sense...

-bawolff

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

Re: [Wikitech-l] License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

2011-11-07 Thread Erik Moeller

On Mon, Nov 7, 2011 at 8:45 AM, Olivier Beaton  wrote:
> The question is should a WMF-funded service (and the MediaWiki
> community) allow 3rd party to make use of said services if they have
> dual-licensed code.

Well, in addition to dual-licensing and asking everyone to contribute
under a dual-license, you want everyone to make a copyright assignment
to you, right?

I'm not sure I understand what benefits this brings -- you imply in
your original note that it's required for BSD dual-licensing, but I
don't see why that's true. Could you elaborate on that?

Thanks,
Erik

-- 
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation

Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate

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

[MediaWiki-CodeReview] [MediaWiki r102297]: New comment added

User "Hashar" posted a comment on MediaWiki.r102297.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102297#c25647
Commit summary:

bug 31990 justify paragraphs pref adds extra space to category listing

When text justification is enabled in user preference, the category list
could show a large space before the first category. Overriding the element
to use left justification is enough to fix the spacing issue albeit the
categories will no more justified.

Thanks to lupo with bug 31990 comments number 8 hinting at the catlinks
element not being properly justified.

This is a regression in REL1_18 and need a backport.

Comment:

Tagging for 1.18 since it is a regression.

Would be nice to have it live too so I am tagging it for 1.18wmf1

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102301]: New comment added

User "Hashar" posted a comment on MediaWiki.r102301.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102301#c25646
Commit summary:

Fix Bug #32047: in table with class="sortable", thead is before
caption

Apply fomafix's patch for jquery.tablesorter.js (also reported upstream:
https://forum.jquery.com/topic/in-table-with-class-sortable-thead-is-before-caption
(currently in moderation)

Comment:

tests added in follow up r102303.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102269]: Revision status changed

User "Awjrichards" changed the status of MediaWiki.r102269.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102269
Commit summary:

need to update the amount, even if it isnt a number so that our amount 
validation is actually checking against what the user has chosen

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102300]: Revision status changed

User "Awjrichards" changed the status of MediaWiki.r102300.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102300
Commit summary:

Adding a relevant title to the SpecialPage

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102292]: Revision status changed

User "Nikerabbit" changed the status of MediaWiki.r102292.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102292
Commit summary:

SocialProfile: follow-up to r102132 as per Nikerabbit's code review: use 
OutputPage's addWikiMsg() instead of addHTML() + wfMsgExt()

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r84814]: Revision status changed

User "Hashar" changed the status of MediaWiki.r84814.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84814
Commit summary:

Topple the last bastion of global-function-based special pages.  Also fix 
HTMLCheckField to work with GET forms.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r84814]: New comment added

User "Hashar" posted a comment on MediaWiki.r84814.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84814#c25645
Commit summary:

Topple the last bastion of global-function-based special pages.  Also fix 
HTMLCheckField to work with GET forms.

Comment:

My patch was r101404 hopefully fixing bug 31770
Still need to write some tests though :(

I am keeping the needs-php-test as a reminder. The whole HTMLForm class really 
needs tests.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

> Copyright assignments are harmful. They are not some sort of standard
> thing in open source. They would be harmful to MediaWiki.

At the risk of de-railing the discussion, I think everyone can agree
that having good high quality extensions for MediaWiki is good for
MediaWiki. The license an extension uses does not harm MediaWiki in
any way. Nor is this discussion really aimed at proposing a
re-licensing of the core. Please stay on-topic.

The question is should a WMF-funded service (and the MediaWiki
community) allow 3rd party to make use of said services if they have
dual-licensed code.

They are already contributing positively to MediaWiki a) they have an
extension we can use that better our lives (maybe) and b) they are
releasing at least a portion of their code with a permissive license
which everyone can benefit from. Whether it be GPL or otherwise.  True
maybe we could benefit MORE, but it's not harming the core or the
community.

- Olivier

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

Re: [Wikitech-l] Wikimedia DC accessibility hackathon this weekend

2011-11-07 Thread Chad

On Mon, Nov 7, 2011 at 11:03 AM, Amir E. Aharoni
 wrote:
> 2011/11/7 Sumana Harihareswara :
>> This Saturday, November 12, Wikimedia DC is hosting an accessibility
>> hackathon 10am to 5:30pm.  RSVP at
>> http://accessibilityhackathon.eventbrite.com/ .
>
> Just reminding that a blind user in Haifa complained about the
> accessibility of the Wikimania registration site. It makes a lot of
> sense to look at that at D.C., too.
>

Just as a minor note, we will not be using EventBrite for
the actual Wikimania registration.

-Chad

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

[MediaWiki-CodeReview] [MediaWiki r102295]: New comment added

User "Hashar" posted a comment on MediaWiki.r102295.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102295#c25644
Commit summary:

bug 29110 - $wgFeedDiffCutoff doesn't affect new pages

Patch by John Du Hart. Rewritten to avoid code duplication, duplicate
code is now in a helper function.

Comment:

That is a really minor bug. I don't think it is worth a back port in 1.18.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] [Ticket#2011091710005702] SVN Extension Access

I'm going to try to continue the conversation wrt process, and how
things can be improved in the future.

> I wish you had found the patience to assume good faith.
Delays are expected in any process. In my case it took 3 weeks before
my request was looked at, and Sumana was always realistic about this
and event sent me a "heads up things are taking awhile" note. While
the delays are regrettable, sometimes they are unavoidable.

What ended up bothering me is a further 4 weeks of back and forth
emails about "can you tell us more about __X__" only to be met with a
"about __Y__" and "about __Z__". Looking at why this is, and how it
can be improved should be Issue #1. Where great customer relations
fails is when the process shows it hasn't followed due-process, it
comes off as sugar coating.

> And, if I may be forgiven for white-knighting, Sumana's job is to needle
> the rest of us so we don't forget about concerns like yours and she generally 
> does it very well.
I don't think Sumana's communication skills wrt writing nicely worded
emails is at issue here, but the process as a whole. It's not my
intention to single out someone in the process.

> IMO the developer who reviewed your code should have contacted you directly.
Having a formal process discourages informal communication. This is a
bit of a given, and doesn't mean process is bad, but I think it's
important to keep things in perspective. Like you say, sometimes a
short informal meeting goes a long way to resolving a lot of
bureaucratic red-tape.

In my case a lot of the back-and-forth seemed centered around
licensing issues, which can be fairly complex (if you take a look at
the robla licensing thread). I tried twice to approach the only point
of contact I had (Sumana) to start a discussion about this informally,
but was met with what I felt was a "sorry the council in session
behind closed doors, please wait until they make their decision" or at
the least "I can't really talk about this without everyone being
here". Again this is not an attack on Sumana personally, but on the
process.

I would of loved it if she had been empowered to say something about
what the issues being discussed were, and be able to further
facilitate communication between the people raising the issues and
myself. I understand sometimes this isn't possible, but given how
active I am in IRC and that I (had) a standing rapport with Sumana and
other developers, this didn't seem out of the question. Instead each
time I waited a week only to learn some new issue was raised. I never
knew who these people raising these issues were (so that I wouldn't
harass them? I admit this can be a a real issue).

Perhaps the assumption of good faith should rest on the review
committee. It seems attractive at first to "process" requests as
quickly as possible, to go "reject reject reject done!", rejecting
them based on their first inconsistency with policy. But this is fake
speed, and only serves to alienate the people who may be contributing
to your project for years to come. No instructor would hand you back
your essay with the first grammar mistake and say "please fix line one
and resubmit", only to then hand it back to you with line 2
highlighted.

I think the review committee should do a complete evaluation of each
request they receive, and provide complete feedback. Even if this took
an extra week, it wouldn't result in the 7 I did. I think establishing
what the things they should look at is worthwhile. Here's a short list
off the top of my head:

a) Code example submitted
b) Their involvement in the community
   I) Wiki
   II) Lists
   III) IRC
c) In the case of extensions, look at what they've put up. Look at the
discussion page if present to see how they communicate with their
users.

> I had a look at the module you wrote. I share some of the same concerns
> about scalability, but that's not really the issue.

You're right, it's not. And ironically if the committee had looked at
the talk page for the Realnames extension, at the very top I had added
a FAQ item (before they looked at my extension) explaining my concerns
about scalability, and how I planned to solve them in future betas
(preferring to release working, iterative code, especially in a new
environment where I wasn't yet sure what the proper thing to do was).

This brings us to an interesting point, that the code sample for
commit access becomes the first code review the developer receives. In
some cases their first interaction with the community. And there is
tremendous worth in this. The commit page indicates MW is ready to
help you learn MW, but they don't want to teach you to program. In
this case I think my experience, and the experience of many others
(see Yaron's colleague, who still does not have access) would be much
improved if they received something like:

"We looked at your code and would be happy to have you join us. Here's
your access so you can get started, it's limited to __X__. Part of
being part of the MW comm

[MediaWiki-CodeReview] [MediaWiki r101551]: Revision status changed

User "Platonides" changed the status of MediaWiki.r101551.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101551
Commit summary:

arrray -> array

Whitespace

Other documentation improvements

Comment out some unused code (which has a fixme left with it already)

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r94171]: New comment added, and revision status changed

User "^demon" changed the status of MediaWiki.r94171.

Old Status: fixme
New Status: new

User "^demon" also posted a comment on MediaWiki.r94171.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/94171#c25643
Commit summary:

(bug 30219) NoLocalSettings.php broken on Windows servers. Per Tim on r70711, 
can't use pathinfo() on url's since the slashes don't match.

Comment:

Setting back to new, there's nothing really left to do here. Release notes and 
docs were updated.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r99022]: Revision status changed

User "^demon" changed the status of MediaWiki.r99022.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/99022
Commit summary:

Actually fix bug 31354 this time (hopefully): expand URLs in the permalink 
dialog if wgServer is protocol-relative

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Wikimedia DC accessibility hackathon this weekend

2011-11-07 Thread Amir E. Aharoni

2011/11/7 Sumana Harihareswara :
> This Saturday, November 12, Wikimedia DC is hosting an accessibility
> hackathon 10am to 5:30pm.  RSVP at
> http://accessibilityhackathon.eventbrite.com/ .

Just reminding that a blind user in Haifa complained about the
accessibility of the Wikimania registration site. It makes a lot of
sense to look at that at D.C., too.

--
Amir

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

[MediaWiki-CodeReview] [MediaWiki r101476]: Revision status changed

User "^demon" changed the status of MediaWiki.r101476.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101476
Commit summary:

bug 32100 installer complains about suhosin GET limit

Our logic was to warn whenever the suhosin GET limit was set.
This patch skip the warning if the limit is 1024 or more.

Also added 'qqq' message for 'config-suhosin-max-value-length'

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[Wikitech-l] Wikimedia DC accessibility hackathon this weekend

2011-11-07 Thread Sumana Harihareswara

This Saturday, November 12, Wikimedia DC is hosting an accessibility
hackathon 10am to 5:30pm.  RSVP at
http://accessibilityhackathon.eventbrite.com/ .

If MediaWiki developers come, they can work on making MediaWiki more
accessible --
https://bugzilla.wikimedia.org/buglist.cgi?keywords=accessibility has
129 bugs right now, so there's a lot of work to be done!  Katie Filbert
(aude), who's running the event, is aiming to get accessibility experts
to the event to help developers improve their apps' accessibility.  She
writes that "at some point, we might do an "audit" of MediaWiki and
identify issues ... maybe on Saturday."

Enjoy!

-- 
Sumana Harihareswara
Volunteer Development Coordinator
Wikimedia Foundation

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

[MediaWiki-CodeReview] [MediaWiki r90409]: Revision status changed

User "^demon" changed the status of MediaWiki.r90409.

Old Status: new
New Status: resolved

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/90409
Commit summary:

Update Chinese conversion tables.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r101067]: Revision status changed

User "^demon" changed the status of MediaWiki.r101067.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101067
Commit summary:

1.18wmf1 MFT r96178, r96182, r99304, r99308, r100219, r100221, r100223, r100226

Like r101065

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r101065]: Revision status changed

User "^demon" changed the status of MediaWiki.r101065.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/101065
Commit summary:

REL1_18 MFT r96178, r96182, r99304, r99308, r100219, r100221, r100223, r100226

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r100223]: Revision status changed

User "^demon" changed the status of MediaWiki.r100223.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100223
Commit summary:

Fix some incorrect rules. Fxxk unihan.zip!

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r100221]: Revision status changed

User "^demon" changed the status of MediaWiki.r100221.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/100221
Commit summary:

Fix a bug existed in Makefile.py which allows single character appearring in 
words list.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r84982]: Revision status changed

User "^demon" changed the status of MediaWiki.r84982.

Old Status: new
New Status: deferred

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84982
Commit summary:

change format for TWN

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r84981]: Revision status changed

User "^demon" changed the status of MediaWiki.r84981.

Old Status: new
New Status: deferred

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84981
Commit summary:

Continue implementation of spec + added some stuff that I had in the TS 
working-copy but not locally.
* defines.txt is now parsable through parse_ini_file
* Instead of executing the 'svn info' shell command; parse .svn/entries (part 
of BaseTool's global kfGetSvnInfo() function.
* Implemented TsItuition::getAvailableLangs() returns array of language-codes 
and their language names for all languages that are currently available (= 
languages in which at least 1 message is defined)
* Temporary workaround to remove 'qqq' from getAvailableLangs by unset() on 
'qqq' when loading messages
* Adding confirmation messages after clearing or renewing cookies eg. 
"Succesfully cleared cookies."
* Renamed message "clear-memory" in "Tsintuition" domain to "clear-cookies"

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r84942]: Revision status changed

User "^demon" changed the status of MediaWiki.r84942.

Old Status: new
New Status: deferred

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84942
Commit summary:

add rev id in header + clear-cookies lowercase

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r84941]: Revision status changed

User "^demon" changed the status of MediaWiki.r84941.

Old Status: new
New Status: deferred

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84941
Commit summary:

adding the rest to SVN

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r84917]: Revision status changed

User "^demon" changed the status of MediaWiki.r84917.

Old Status: new
New Status: deferred

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84917
Commit summary:

adding initial languages dir

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r84916]: Revision status changed

User "^demon" changed the status of MediaWiki.r84916.

Old Status: new
New Status: deferred

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/84916
Commit summary:

adding def. file for Nike

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

2011-11-07 Thread David Gerard

On 7 November 2011 15:08, Olivier Beaton  wrote:

> To make it clear, copyright assignments (what I had in my original
> request) are common in the FOSS community, as you pointed out you
> talked about them yourself on your blog and wmf talked about having

Copyright assignments are inherently harmful, as their only use is so
that the assigned-to body can defect on the implicit covenant of open
source: that is, so it can take people's contributions private.

The FSF continues to use them, on the theory that this gives greater
legal protection. While the FSF is quite unlikely to defect (it's
spent twenty-five years behaving as a consistent actor), its legal
theory appears unnecessary (neither the Linux kernel nor BusyBox use
copyright assignments, but both have been spectacularly successful in
pursuing GPL violations) and its continued use makes people think
they're a good idea.

For an example of defection, see Oracle taking MySQL open-core.

Copyright assignments are harmful. They are not some sort of standard
thing in open source. They would be harmful to MediaWiki.

- d.

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

[MediaWiki-CodeReview] [MediaWiki r102289]: New comment added

User "Hashar" posted a comment on MediaWiki.r102289.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102289#c25642
Commit summary:

fix badly named variable

Resource takes two S in french :D
follow up r102286

Comment:

Thanks Nike for the review!

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102286]: New comment added

User "Hashar" posted a comment on MediaWiki.r102286.

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102286#c25641
Commit summary:

dieout when file is a boolean

On file operation errors, the file variable can be assigned boolean false
which is not a valid handle. Those backtrace can help users debug an issue
when generating a filemap.

Comment:

Typo (ressource) fixed in follow up.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

Re: [Wikitech-l] Finding our old committers

2011-11-07 Thread Chad

On Mon, Nov 7, 2011 at 8:42 AM, Chad  wrote:
> Hi everyone,
>
> I'm working on the Git migration project, and I need your help!
>
> Unlike SVN which stores commits based on a username, Git stores
> a commit attributed to a name + e-mail address. I've made a lot of
> progress on figuring these out, but I've gotten the list narrowed down
> and I'm getting a little stuck on some of the old accounts that aren't
> active anymore.
>
> So I thought I'd ask if people on the list could take a look at my
> unknown committers list[0] and see which people they know and can
> figure out. I'm finding that lots of people know about one or two of the
> people on the list.
>
> If you know the name or the e-mail address of any of the users that
> we've got listed there, fill it in. Thanks for any help you can provide!
>
> -Chad
>
> [0] http://etherpad.wikimedia.org/Unknown-committers
>

Wow, I didn't expect such a quick response! Thanks to Niklas, CoE, Andre
Engels, Liangent, Merlijn and all of the other anonymous people who dropped
in. We've already managed to get quite a few of the names filled out.

Thank you thank you!

-Chad

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

Re: [Wikitech-l] License exceptions in Wikimedia's repo (was Re: SVN Extension Access)

I think continuing the license discussion is worthwhile.

For the purpose of this conversation as I see it the WikiMedia
Foundation is providing services (defined next) to two facets of the
MediaWiki community (core and extensions developers):
a) Repository to store/revision code (svn or soon git)
b) Code review mechanism with community as participants (more for core
but usable by extensions)
c) Permissive environment where the community can help the community
(commit in on each other's code)
d) Continuous integration testing (again more for core... is this
usable by extensions somehow?)
e) Packaging for both core and extensions with backwards-compatibility
helpers (this is huge for extensions)

This is great and I hope WMF keeps providing these resources, not just
to core but also all extensions developers who would benefit. Given
that WMF is providing it, they are setting some requirements about how
and in what situations it can be used, as well as vetting who can use
it. As long as the requirements are not too strict, this seems
reasonable and doesn't devalue the service in the first place (and in
turn harm MediaWiki).

The current attitude by the MediaWik communityi as a whole to anyone
walking in on IRC (you have code? commit ASAP!), these lists (see the
message a few days ago -- just get commit access its easier if you
check these changes in yourself), and the wiki access pages themselves
(as long as you're a competent programmer, we'll take you).

Given these factors I think it's important to be as permissive as
possible in terms of licensing to allow the widest range of
contributors, while still enforcing a minimum standard that ensure the
community benefits as well from people using the services.

As you mentioned below, changing someone's license on their extension,
while sometimes legal, is definitely a no go. In my mind at that point
you're forking their project, and saying "well now you can contribute
to my fork if you like"... I don't expect such a stipulation to be
contested much.

> Olivier, I'm sorry your access request didn't go the way you hoped,
To be clear, I had spent the last 7 weeks "justifying" my request with
no feedback. It's not about a yes/no. But more on that in another
thread, this is about licensing issues neh?

> but this issue alone is enough to torpedo your access request.
It shouldn't torpedo anything. As the community grows you will
encounter people wanting to use their own licenses on their own code
in their own modules more and more. Having a strict requirement to use
what I dare call community services is harmful to MediaWiki.

To make it clear, copyright assignments (what I had in my original
request) are common in the FOSS community, as you pointed out you
talked about them yourself on your blog and wmf talked about having
one for MediaWiki at one time. They are most common and beneficial for
GPL'ed projects that wish to dual-license. So here's question #1,
which you seem to have given your stance on, and leveraged WMF behind.

Q1. Should WMF allow Dual-Licensed extensions in the MediaWiki repo?

Is community consensus even worth gathering, or is this a "closed
issue"? If you look at a community like Wordpress, there is a lot of
commercial players involved in their plugin ecosystem. Of course they
can always host and make their own tools, but does turning them away
from community incentives to come to MediaWiki the right choice?

Q2. Should people using any OSI approved license without modification
be able to use the MediaWiki repo?

You mentioned in your mail GPL v2, BSD, MIT, LGPL (and similar) but
excluded mentioned a soft exclusion for GPL v3.  This seems overly
restrictive for extensions. As some people mentioned on the lists
already, maybe just blanket approving anything OSI approved seems
wise? If you can legally fork it, it seems like that should be enough,
the community will always be able to benefit from that code. If having
the code be compatible with core licensing (so that you can fold code
in) is important, then any GPL-compatible license may work.

Q3. Should people who add a clause to their license that all
contributions are to be made under the same license be turned away?

This is similar to how the GPL comes with a clause that requires all
contributions to be GPL'ed (except with the distribution requirement,
so is still more commercial friendly).  If someone adds a similar
clause to their license (say a BSD license), can they still make use
of the services? Of course given Q2 there is the issue of whether such
a clause invalidates GPL-compliance, or how it could be worded so as
not to.

And here's where I currently stand with my own work. I'm no expert on
licensing and my wording so far may not be great, but there seems to
be some concern in BSD-like licenses that without such a clause in a
shared-commit environment can lead to trouble. Zend Framework is
BSD-3-Clause'd and has a contributor agreement to handle IP issues
(and not for any dual-lice

[MediaWiki-CodeReview] [MediaWiki r102279]: Revision status changed

User "Nikerabbit" changed the status of MediaWiki.r102279.

Old Status: deferred
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102279
Commit summary:

svn:eol-style native

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102277]: Revision status changed

User "Nikerabbit" changed the status of MediaWiki.r102277.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102277
Commit summary:

Update date format for dsb and hsb: month names need the genitive, make them 
consistent
Per discussion on 
https://translatewiki.net/wiki/Thread:User_talk:Raymond/Formatierung_einer_Datumsvariable

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102276]: Revision status changed

User "Nikerabbit" changed the status of MediaWiki.r102276.

Old Status: new
New Status: ok

Full URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/102276
Commit summary:

streamError now reuses Outputpage

StreamError was reimplementing HTTP Error code already available in
includes/lib/httpstatus.php . So we are now reusing the code logic from
OutputPage and limit code duplication.

___
MediaWiki-CodeReview mailing list
mediawiki-coderev...@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview

[MediaWiki-CodeReview] [MediaWiki r102209]: New comment added