date:20130305

On Mar 3, 2013, at 7:04 AM, Chad innocentkil...@gmail.com wrote:

 On Sat, Mar 2, 2013 at 9:56 PM, Jeremy Baron jer...@tuxmachine.com wrote:
 On Sun, Mar 3, 2013 at 5:50 AM, Brion Vibber br...@pobox.com wrote:
 Is anybody else seeing this when running 'git submodule update' in a
 checkout of the extensions repo?
 
  fatal: reference is not a tree: beead919cac17528f335d9409dfcada12e606ebd
  Unable to checkout 'beead919cac17528f335d9409dfcada12e606ebd' in
 submodule path 'MaintenanceShell'
 
 Seems like the submodule's gotten broken somehow?
 https://gerrit.wikimedia.org/r/51887 attempts to fix it manually...
 
 Well it does exist:
 
 https://gerrit.wikimedia.org/r/gitweb?p=mediawiki%2Fextensions%2FMaintenanceShell.git;a=commit;h=beead919cac17528f335d9409dfcada12e606ebd
 
 But that's not in the log of the current master. Must have had a force
 push bypassing review. (which makes sense if you look at the history)
 Maybe not updating the parent repo is a gerrit bug.
 
 
 The auto-updating submodule magic only works if you're pushing
 through Gerrit. Skip Gerrit, and you don't get the benefits of the
 magic submodules.
 
 -Chad

Even if after a force push changes are merged by Gerrit the normal way?

I did a one-time import of the original history, replacing the empty 
repository.

After that I merged 3 changes via Gerrit[1] and there have been no forced
pushes since.

-- Krinkle

[1] as indicated by the pink ref/changes labels:
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/extensions/MaintenanceShell.git;a=summary
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Global user CSS and JS

Not rubbish - that would be quite useful. The only problem is it would 
be a somewhat limited use case. Many users never go near their css/js, 
so it would just be another checkbox for them to ignore, and those who 
do use global css/js would just as likely have wider scope issues than 
that - only works on english projects, only applies where they have 
rollback, or don't have rollback, etc - and at that point it would be a 
lot easier and more effective for them to just add a check to the 
particular script/css rule that it is on an applicable project before it 
runs.


Although that does assume the user actually understands what they're 
putting in their user css/js files.


On 05/03/13 13:43, Paul Selitskas wrote:

I may be saying rubbish, but...

I think we should have a checkbox in Preferences where we can switch off
global JS and CSS for the wiki where this checkbox is set/unset. Let's
imagine I have a script which fits well for every project but Wikidata.
Then I go to the preferences and just disable the global script in Wikidata.


On Tue, Mar 5, 2013 at 4:00 AM, James Forrester jforres...@wikimedia.orgwrote:


On 4 March 2013 14:59, Krenair kren...@gmail.com wrote:

On 04/03/13 22:57, Matthew Flaschen wrote:

Has anyone looked at allowing a user to have global CSS and JS across
all WMF wikis?

I know you can hack it with a mw.loader.load on all the wikis you use,
but it would be useful if CentralAuth had it built in.

Is there a bug for this?

It seems so, yes: https://gerrit.wikimedia.org/r/7274

Bug: https://bugzilla.wikimedia.org/13953

Yes, it would be really lovely to get this enhancement fulfilled
(either with that or new code); it's now on the backlog for admin
tools development[*].

(I speak conflicted, as someone who's used the bot to fake this
globally for my staff account.)

[*] -
https://www.mediawiki.org/wiki/Admin_tools_development/Roadmap#Other_tasks

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

jforres...@wikimedia.org | @jdforrester

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






--
-— Isarra


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

Re: [Wikitech-l] QUnit testing in Jenkins

On Mar 5, 2013, at 3:49 PM, Dan Andreescu dandree...@wikimedia.org wrote:

From console[1]:

02:50:21 Testing

http://localhost:9412/mediawiki-core-28a705a9f648da310ff2a4fca9d013bf147f3d1f/index.php?title=Special:JavaScriptTest/qunitExceptionthrown
by test.module1: expected
02:50:21 Error: expected
02:50:24 OK
02:50:24 832 assertions passed (5350ms)
02:50:24
02:50:24 Done, without errors.

This is strange. The console says there was a problem: Exception thrown
by
test.module1: expected and Error: expected
But then it says everything is fine: Done, without errors.

Željko
--
[1]
https://integration.mediawiki.org/ci/job/mediawiki-core-qunit/3/console

I'm not sure how to navigate to the source that defines that test but I
suspect it's just using an expected exception test:
http://docs.jquery.com/QUnit/raises

No, it is neither.

Remember you're looking at the console log. Which, in this case is
being written two from lots of sources:

* jenkins - stdout
* grunt/qunit - stdout
* phantomjs - console.log()

The part cited here is mostly qunit's output (the dotted progress
line), but when calling console.log from within the javascript it is
forwarded to the jenkins console.

A console log is harmless and no reason for alarm. If it were an
actual exception, it wouldn't be tolerated.

In this case it is coming from the unit tests that asserts that
mw.loader sets a module's state to error if it's javascript bundle
throws an exception. mw.loader executes the bundle in a try/catch and
logs any exceptions to the console after which it sets state=error and
triggers the error callbacks.

Right now grunt/qunit forwards the phantomjs console straight to the
main output. It would be prettier if it would display it in a way that
more clearly says phantomjs console. I requested this 3 months ago:
https://github.com/gruntjs/grunt-contrib-qunit/pull/6

Execute the tests in your own browser and you'll see the same data in
your browser's console (e.g. Chrome Dev Tools).

-- Krinkle

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

Re: [Wikitech-l] Seemingly proprietary Javascript

I would just like to note that while it may be silly or useless to
insert licenses into minified JavaScript, it is nonetheless *legally
required* to do so, regardless of the technical aspect of it. And it is not
a question of whether we want to support some labeling program that reads
JavaScript licenses; both the GPL and CC licenses have requirements that
when you convey source code or binaries through any medium that the license
be prominently displayed. I strongly doubt that a company is going to sue
the WMF for something like this, but even so it's not a good idea to
specifically ignore legal requirements for a third-party software.

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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Marc A. Pelletier


On 03/05/2013 12:22 PM, Tyler Romeo wrote:

it is nonetheless *legally
required* to do so, regardless of the technical aspect of it


I think that determination needs to be made by Counsel, not on a guess.  
I've quite some knowledge of copyright myself, and I know enough that 
the matter is subtle enough that this declaration is, at best, an 
oversimplification that cannot possibly reflect reality.


-- Marc


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

Re: [Wikitech-l] Global user CSS and JS

2013-03-05 Thread James Forrester

You can of course always counter-over-ride your global JS/CSS locally - the
composite rule would presumably be changed to:

1. file,
2. site
3. skin,
*. global-user
4. local-user

… - so you could fix local incompatibilities.

On 5 March 2013 09:14, Isarra Yos zhoris...@gmail.com wrote:

Not rubbish - that would be quite useful. The only problem is it would be
a somewhat limited use case. Many users never go near their css/js, so it
would just be another checkbox for them to ignore, and those who do use
global css/js would just as likely have wider scope issues than that - only
works on english projects, only applies where they have rollback, or don't
have rollback, etc - and at that point it would be a lot easier and more
effective for them to just add a check to the particular script/css rule
that it is on an applicable project before it runs.

Although that does assume the user actually understands what they're
putting in their user css/js files.

On 05/03/13 13:43, Paul Selitskas wrote:

I may be saying rubbish, but...

I think we should have a checkbox in Preferences where we can switch off
global JS and CSS for the wiki where this checkbox is set/unset. Let's
imagine I have a script which fits well for every project but Wikidata.
Then I go to the preferences and just disable the global script in
Wikidata.

On Tue, Mar 5, 2013 at 4:00 AM, James Forrester jforres...@wikimedia.org
**wrote:

On 4 March 2013 14:59, Krenair kren...@gmail.com wrote:

On 04/03/13 22:57, Matthew Flaschen wrote:

Has anyone looked at allowing a user to have global CSS and JS across
all WMF wikis?

I know you can hack it with a mw.loader.load on all the wikis you use,
but it would be useful if CentralAuth had it built in.

Is there a bug for this?

It seems so, yes:
https://gerrit.wikimedia.org/**r/7274https://gerrit.wikimedia.org/r/7274

Bug:
https://bugzilla.wikimedia.**org/13953https://bugzilla.wikimedia.org/13953

Yes, it would be really lovely to get this enhancement fulfilled
(either with that or new code); it's now on the backlog for admin
tools development[*].

(I speak conflicted, as someone who's used the bot to fake this
globally for my staff account.)

[*] -
https://www.mediawiki.org/**wiki/Admin_tools_development/**
Roadmap#Other_taskshttps://www.mediawiki.org/wiki/Admin_tools_development/Roadmap#Other_tasks

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

jforres...@wikimedia.org | @jdforrester

__**_
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l

--
-— Isarra

__**_
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

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

Re: [Wikitech-l] Global user CSS and JS

Not rubbish - that would be quite useful. The only problem is it would 
be a somewhat limited use case. Many users never go near their css/js, 
so it would just be another checkbox for them to ignore, and those who 
do use global css/js would just as likely have wider scope issues than 
that - only works on english projects, only applies where they have 
rollback, or don't have rollback, etc - and at that point it would be a 
lot easier and more effective for them to just add a check to the 
particular script/css rule that it is on an applicable project before it 
runs.


Although that does assume the user actually understands what they're 
putting in their user css/js files.


On 05/03/13 13:43, Paul Selitskas wrote:

I may be saying rubbish, but...

I think we should have a checkbox in Preferences where we can switch off
global JS and CSS for the wiki where this checkbox is set/unset. Let's
imagine I have a script which fits well for every project but Wikidata.
Then I go to the preferences and just disable the global script in Wikidata.


On Tue, Mar 5, 2013 at 4:00 AM, James Forrester jforres...@wikimedia.orgwrote:


On 4 March 2013 14:59, Krenair kren...@gmail.com wrote:

On 04/03/13 22:57, Matthew Flaschen wrote:

Has anyone looked at allowing a user to have global CSS and JS across
all WMF wikis?

I know you can hack it with a mw.loader.load on all the wikis you use,
but it would be useful if CentralAuth had it built in.

Is there a bug for this?

It seems so, yes: https://gerrit.wikimedia.org/r/7274

Bug: https://bugzilla.wikimedia.org/13953

Yes, it would be really lovely to get this enhancement fulfilled
(either with that or new code); it's now on the backlog for admin
tools development[*].

(I speak conflicted, as someone who's used the bot to fake this
globally for my staff account.)

[*] -
https://www.mediawiki.org/wiki/Admin_tools_development/Roadmap#Other_tasks

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

jforres...@wikimedia.org | @jdforrester

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






--
-— Isarra


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

Re: [Wikitech-l] Reminder about the best way to link to bugs in commits

2013-03-05 Thread Bartosz Dziewoński


On Mon, 04 Mar 2013 17:03:58 +0100, Tim Landscheidt t...@tim-landscheidt.de 
wrote:


Bartosz Dziewoński matma@gmail.com wrote:



I wrote a very simple one some time ago, in Ruby. 
https://github.com/MatmaRex/mediawikireleasenotes-driver



It doesn't really work. There are enough changes that are not simple additions 
that it solves no more than about 30% conflics for me. Maybe that rate could be 
improved using, like, a real algorithm for merging; but the naive solution 
doesn't really work.


[...]

Let's add your driver to
http://www.mediawiki.org/wiki/Git/Workflow#Build_failed_due_to_merge_conflict.


Please go ahead if you think it's worth it. I didn't because in general I 
deemed the result not good enough, and when the automatic merge fails, you lose 
the information about branches being merged (try it).



I think it's probably preferable to have a separate file for
the driver itself and manual installation instructions as
otherwise people will just complain
mediawikireleasenotes-driver-installer.sh didn't work for
my setup!!11!, but that's no blocker.


I can't imagine a setup where it wouldn't just work (other than you not running 
the installer inside a .git directory). And sharing the file + instructions 
insted of the installer is a big can of worms. (Where do you store the .rb 
driver file? Where do you add the entry for merging RELEASE-NOTES? Which config 
do you edit? How? git has a lot of options for all these things...)


--
Matma Rex

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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Luke Welling WMF

Yes.  There seems little value in unqualified people debating if it is
legally required.

The mainstream FOSS licences all predate minification and seem to have been
written with compiled languages in mind, not interpreted languages.  Most
have language that requires the licence in the source version, but not the
binary version.  Deciding whether minified JavaScript is technically or in
spirit a binary form seems like something best left to experts.

My conscience would certainly be clear if we only had a licence in our
source distribution.

Luke


On Tue, Mar 5, 2013 at 12:25 PM, Marc A. Pelletier m...@uberbox.org wrote:

 On 03/05/2013 12:22 PM, Tyler Romeo wrote:

 it is nonetheless *legally
 required* to do so, regardless of the technical aspect of it


 I think that determination needs to be made by Counsel, not on a guess.
  I've quite some knowledge of copyright myself, and I know enough that the
 matter is subtle enough that this declaration is, at best, an
 oversimplification that cannot possibly reflect reality.

 -- Marc



 __**_
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] Seemingly proprietary Javascript

On Tue, Mar 5, 2013 at 12:25 PM, Marc A. Pelletier m...@uberbox.org wrote:

 I think that determination needs to be made by Counsel, not on a guess.
 I've quite some knowledge of copyright myself, and I know enough that the
matter is subtle enough that this declaration is, at best, an
oversimplification that cannot possibly reflect reality.


Agreed, but even without legal training it's pretty clear this is a
requirement. Quoting from CC-BY-SA:

 You must include a copy of, or the Uniform Resource Identifier for, this
License with every copy or phonorecord of the Work You distribute, publicly
display, publicly perform, or publicly digitally perform. [...] ou must
keep intact all notices that refer to this License and to the disclaimer of
warranties.


And then in the GPL:

 b) The work must carry prominent notices stating that it is released
under this License and any conditions added under section 7. This
requirement modifies the requirement in section 4 to “keep intact all
notices”.


Later in the license it specifies that also binary forms of the work that
are conveyed must also comply with these restrictions.

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

Re: [Wikitech-l] Reminder about the best way to link to bugs in commits

2013-03-05 Thread Yuri Astrakhan

All these issues with the git-side driver is the reason I think we should
have a master-branch-monitoring bot that will update RELEASE-NOTES based on
commit messages. Easy to track changes, easy to fix problems. Might be a
bit more work than a driver though.

On Tue, Mar 5, 2013 at 12:30 PM, Bartosz Dziewoński matma@gmail.comwrote:

On Mon, 04 Mar 2013 17:03:58 +0100, Tim Landscheidt
t...@tim-landscheidt.de wrote:

Bartosz Dziewoński matma@gmail.com wrote:

I wrote a very simple one some time ago, in Ruby.
https://github.com/MatmaRex/**mediawikireleasenotes-driverhttps://github.com/MatmaRex/mediawikireleasenotes-driver

It doesn't really work. There are enough changes that are not simple
additions that it solves no more than about 30% conflics for me. Maybe that
rate could be improved using, like, a real algorithm for merging; but the
naive solution doesn't really work.

[...]

Let's add your driver to
http://www.mediawiki.org/wiki/**Git/Workflow#Build_failed_due_**
to_merge_conflicthttp://www.mediawiki.org/wiki/Git/Workflow#Build_failed_due_to_merge_conflict
.

Please go ahead if you think it's worth it. I didn't because in general I
deemed the result not good enough, and when the automatic merge fails, you
lose the information about branches being merged (try it).

I think it's probably preferable to have a separate file for
the driver itself and manual installation instructions as
otherwise people will just complain
mediawikireleasenotes-driver-**installer.sh didn't work for
my setup!!11!, but that's no blocker.

I can't imagine a setup where it wouldn't just work (other than you not
running the installer inside a .git directory). And sharing the file +
instructions insted of the installer is a big can of worms. (Where do you
store the .rb driver file? Where do you add the entry for merging
RELEASE-NOTES? Which config do you edit? How? git has a lot of options for
all these things...)

--
Matma Rex

__**_
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] Github/Gerrit mirroring

2013-03-05 Thread Jon Robson

I was wondering what the latest on this was (I can't seem to find any
recent updates in my mailing list). The MobileFrontend project was
reassured to see a github user commenting on our commits in github.
It's made me more excited about a universe where pull requests made in
github show up in gerrit and can be merged. How close to this dream
are we?

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

Re: [Wikitech-l] Seemingly proprietary Javascript

The licensing information is on the page itself, of which the minified 
js winds up a part. For every file or other object that makes up the 
page to all contain the licensing information would be pretty unusual.


It's like taking a file out of a page and then complaining that it has 
no licensing information when said information was in the page text 
right under it.


On 05/03/13 17:36, Tyler Romeo wrote:

On Tue, Mar 5, 2013 at 12:25 PM, Marc A. Pelletier m...@uberbox.org wrote:

I think that determination needs to be made by Counsel, not on a guess.

  I've quite some knowledge of copyright myself, and I know enough that the
matter is subtle enough that this declaration is, at best, an
oversimplification that cannot possibly reflect reality.


Agreed, but even without legal training it's pretty clear this is a
requirement. Quoting from CC-BY-SA:


You must include a copy of, or the Uniform Resource Identifier for, this

License with every copy or phonorecord of the Work You distribute, publicly
display, publicly perform, or publicly digitally perform. [...] ou must
keep intact all notices that refer to this License and to the disclaimer of
warranties.


And then in the GPL:


b) The work must carry prominent notices stating that it is released

under this License and any conditions added under section 7. This
requirement modifies the requirement in section 4 to “keep intact all
notices”.


Later in the license it specifies that also binary forms of the work that
are conveyed must also comply with these restrictions.

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



--
-— Isarra


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

Re: [Wikitech-l] PHP Analyzer (now open-source!)

2013-03-05 Thread Antoine Musso

Le 04/03/13 11:03, Tyler Romeo a écrit :
  Do you mind sharing the package/source code link?
 
 https://github.com/scrutinizer-ci/php-analyzer

Go ahead and play with it on a labs instance.  If you could manage to
get an output generated for mediawiki/core that will give us an idea
about the usefulness of such tool.

I will be more than happy to integrate it in Jenkins if we end up being
interested in such analyse.

-- 
Antoine hashar Musso


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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Caroline E Willis

Is there a Counsel we can refer this to?
On Mar 5, 2013 11:47 AM, Isarra Yos zhoris...@gmail.com wrote:

The licensing information is on the page itself, of which the minified js
winds up a part. For every file or other object that makes up the page to
all contain the licensing information would be pretty unusual.

It's like taking a file out of a page and then complaining that it has no
licensing information when said information was in the page text right
under it.

On 05/03/13 17:36, Tyler Romeo wrote:

On Tue, Mar 5, 2013 at 12:25 PM, Marc A. Pelletier m...@uberbox.org
wrote:

I think that determination needs to be made by Counsel, not on a guess.

I've quite some knowledge of copyright myself, and I know enough that
the
matter is subtle enough that this declaration is, at best, an
oversimplification that cannot possibly reflect reality.

Agreed, but even without legal training it's pretty clear this is a
requirement. Quoting from CC-BY-SA:

You must include a copy of, or the Uniform Resource Identifier for, this

License with every copy or phonorecord of the Work You distribute,
publicly
display, publicly perform, or publicly digitally perform. [...] ou must
keep intact all notices that refer to this License and to the disclaimer
of
warranties.

And then in the GPL:

b) The work must carry prominent notices stating that it is released

under this License and any conditions added under section 7. This
requirement modifies the requirement in section 4 to “keep intact all
notices”.

Later in the license it specifies that also binary forms of the work that
are conveyed must also comply with these restrictions.

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

--
-— Isarra

__**_
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] Seemingly proprietary Javascript

On Mar 5, 2013, at 6:22 PM, Tyler Romeo tylerro...@gmail.com wrote:

 I would just like to note that while it may be silly or useless to
 insert licenses into minified JavaScript, it is nonetheless *legally
 required* to do so, regardless of the technical aspect of it. And it is not
 a question of whether we want to support some labeling program that reads
 JavaScript licenses; both the GPL and CC licenses have requirements that
 when you convey source code or binaries through any medium that the license
 be prominently displayed. I strongly doubt that a company is going to sue
 the WMF for something like this, but even so it's not a good idea to
 specifically ignore legal requirements for a third-party software.
 

Sure, but it depends on your definition of prominently displayed.

First off, I agree our javascript files should have license headers in form of
a code comment on top of the files (like we do for PHP files). But only to
clarify their license, not because it is required. Because we already have a
general LICENSE in our distribution, which if I recall correctly explicitly
states that unless otherwise indicated, all is under said license. We don't
have a license header in our release notes, in jpg, png, svg, sql files etc. A
good example (to make it more complicated) is our README where we mention
certain PNG file (cc icons) and JS files (sajax) are from a different author
and license. We don't alter their PNGs and JS files, instead we mention it
elsewhere (whether it belongs in README is another question).

However I don't think it makes sense in any way for this to be sent to the
browser.

A few examples.

## Media in wiki pages

We don't display the license or attribution of images inside the article near
to the image. You go the the image descriptions page (by clicking the image)
and there it is.

## Content of wiki pages

We do display the license on the bottom of every page (which is about the wiki
content, not the software). But not the authors. You go to the History page of
the current article and find a list of contributors there. Note that the user
doesn't click on the content here, but on the History tab.

## Server-side code in the software

Any program code in our software that is not sent to the client. But its
result is sent to the client. Everything you see on the wiki is the result of
executing that server-side code. And if you consider HTML to be part of what
you see, then there's actually a significant amount of server-side code
being sent to the client, because that is literally or abstractly (Html.php)
explicitly written in the code.

## Client-side code in the software

Any program code in our software that is sent to the client (css, javascript).
These are commonly combined and minified, which means HTTP headers are not an
option (unless you'd implement offsets or delimiters correlating to the
content).

## Media in the software

Any interface images and icons in our software. These are commonly embedded as
base64 encoded data, which means HTTP headers are not a feasible method for
delivery of information.

## Media in print

A photograph used in a magazine or print. It might have the
license/attribution over top of the image or closely to it, but it isn't
uncommon for there to be a dedicated page for it. That then refers back to the
images (by page number, position and/or by title) to disclose the license and
attribution. If you'd look at any single spread (e.g. open it on page 3, you
see page 3 and 4) you wouldn't have a complete legal picture. The same if you
take out a page and access it directly. And even more so if you were to take
scissors and take out an individual photo, in which case you'd lose the info
even if it was printed right next to it.

## Conclusion

So let's take the extremes and sum them up:

* A page can contain multiple pieces of content from different sources
(software interface, wiki page content, wiki media embedded) that can all be
from different authors under different licenses (some might even be non-free,
e.g. when embedding fair use, though lets avoid that can of worms for now).

* Our wiki text source does not have license headers. Instead the platform on
which they are primarily displayed (accessing html pages) has a footer. When
accessing it from the API you're circumventing the main portal and are
expected as a consumer to check out the primary access point to find out the
license and author.

* Like wise, accessing a multi-media file[1][2] directly does not give you
attribution or license information in the file itself or in its headers, not
even a link to it. I presume the rationale here is similar to the Media in
print example. One might argue that because it is accessible over a separate
http request it needs to be standalone, but I'm not sure thats justifiable. It
is an implementation detail of how the web works. You can't require everything
to be in the same web request (imagine MediaWiki ajax loading of article
contents, the footer

Re: [Wikitech-l] QUnit testing in Jenkins

2013-03-05 Thread Erik Moeller

On Mon, Mar 4, 2013 at 8:07 PM, Ori Livneh o...@wikimedia.org wrote:

 Today I sprinted to pick up QUnit testing in Jenkins and get it
 stabilised and deployed.

 This is fantastic. Thanks, Timo.

Indeed - this is a great milestone. Thanks for all your work getting
this out the door, Timo! :-)

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

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

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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Luis Villa

On Tue, Mar 5, 2013 at 10:10 AM, Caroline E Willis
cewillism...@gmail.comwrote:

 Is there a Counsel we can refer this to?


Yes. :) This was already on my radar, and I am following this discussion
(which has been useful; specifically, I did not know about the bug already
filed on the issue).

For those of you who don't know me, I'm new to the foundation, but have
been around foss and foss licensing for a while; a good backgrounder on me
is here:
http://www.mail-archive.com/wikimediaannounce-l@lists.wikimedia.org/msg00523.html

Luis


 On Mar 5, 2013 11:47 AM, Isarra Yos zhoris...@gmail.com wrote:

  The licensing information is on the page itself, of which the minified js
  winds up a part. For every file or other object that makes up the page to
  all contain the licensing information would be pretty unusual.
 
  It's like taking a file out of a page and then complaining that it has no
  licensing information when said information was in the page text right
  under it.
 
  On 05/03/13 17:36, Tyler Romeo wrote:
 
  On Tue, Mar 5, 2013 at 12:25 PM, Marc A. Pelletier m...@uberbox.org
  wrote:
 
  I think that determination needs to be made by Counsel, not on a guess.
 
I've quite some knowledge of copyright myself, and I know enough that
  the
  matter is subtle enough that this declaration is, at best, an
  oversimplification that cannot possibly reflect reality.
 
 
  Agreed, but even without legal training it's pretty clear this is a
  requirement. Quoting from CC-BY-SA:
 
   You must include a copy of, or the Uniform Resource Identifier for,
 this
 
  License with every copy or phonorecord of the Work You distribute,
  publicly
  display, publicly perform, or publicly digitally perform. [...] ou must
  keep intact all notices that refer to this License and to the disclaimer
  of
  warranties.
 
 
  And then in the GPL:
 
   b) The work must carry prominent notices stating that it is released
 
  under this License and any conditions added under section 7. This
  requirement modifies the requirement in section 4 to “keep intact all
  notices”.
 
 
  Later in the license it specifies that also binary forms of the work
 that
  are conveyed must also comply with these restrictions.
 
  --
  Tyler Romeo
  Stevens Institute of Technology, Class of 2015
  Major in Computer Science
  www.whizkidztech.com | tylerro...@gmail.com
  __**_
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 
 
 
  --
  -— Isarra
 
 
  __**_
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
 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




-- 
Luis Villa
Deputy General Counsel
Wikimedia Foundation
415.839.6885 ext. 6810

NOTICE: *This message may be confidential or legally privileged. If you
have received it by accident, please delete it and let us know about the
mistake. As an attorney for the Wikimedia Foundation, for legal/ethical
reasons I cannot give legal advice to, or serve as a lawyer for, community
members, volunteers, or staff members in their personal capacity.*
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Ryan Kaldari


On 3/5/13 5:53 AM, Helder . wrote:

On Tue, Mar 5, 2013 at 8:56 AM, Alexander Berntsen alexan...@plaimi.net wrote:

On 05/03/13 11:38, Wikipedia information team wrote:

All of the MediaWiki[1] code base that Wikipedia is licensed
under the GPL[2], including the JavaScript. Also included in
that is the freely-licensed (MIT) jQuery[3] library. However
some code is actually written by the invidual users, like
English Wikipedia's custom javascript[4], which is licensed as
CC-BY-SA-3.0 since all content pages are automatically licensed
that way[5].

Is that really the case? See e.g.:
https://commons.wikimedia.org/wiki/Commons:Village_pump/Archive/2012/08#Does_Commons_only_accept_code_which_can_be_used_for_evil.3F


Yes, that's really the case. We took JSMin out of MediaWiki because of 
it's stupid evil license.


Ryan Kaldari

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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Jay Ashworth

- Original Message -
 From: Mark Holmquist mtrac...@member.fsf.org

 The minification process, however, does *not* cause a problem. We can
 simply add the comments to the file(s) after the minification. It does
 mean we'll need to include, potentially, multiple license headers in
 one HTTP response, but that shouldn't cause much issue.

I am neither an engineer, nor a WMF staffer, but I want to throw a flag
here anyway.

Yes, it will cause an issue.  If that extra data is going in every reply,
multiply its size by our replies per day count, won't you?  I don't know 
what that number is, but I'm quite certain it's substantial. 

*Every single byte* that goes in a place where it will be included in every 
reply directly affects our 95%ile data transfer, I should think, and thus
our budget.  Bytes are not always free.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth  Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

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

Re: [Wikitech-l] Github/Gerrit mirroring

On Mar 5, 2013, at 6:39 PM, Jon Robson jdlrob...@gmail.com wrote:

 I was wondering what the latest on this was (I can't seem to find any
 recent updates in my mailing list). The MobileFrontend project was
 reassured to see a github user commenting on our commits in github.
 It's made me more excited about a universe where pull requests made in
 github show up in gerrit and can be merged. How close to this dream
 are we?
 

I'm not sure to what extend we should make it show up in Gerrit.

But there is https://bugzilla.wikimedia.org/show_bug.cgi?id=35497

Where it is explained that it is trivial to take a PR and submit it to Gerrit.

Though one could write a tool to simplify it, there isn't much to simplify.

Someone with access to Gerrit (anyone with a labs account) only has to:
* Check it out locally.
* Squash it[1] and amend with no modifications (just `git commit --amend -C
  HEAD`; which will trigger your git-review hook to add a Change-Id).
* Push to Gerrit.

If it is submitted as a pull request on GitHub, the communication with the
author and revisions of the patch should be on GitHub. We only submit it to
Gerrit once it is pretty much finalised.

Otherwise the user is going to be unable to answer and act on the feedback.

I assume the reason we are not disabling Pull requests, which is possible, is
because we want this. If all we do is immediately copy the PR, submit it to
Gerrit and close the PR saying Please create a WMFLabs account, learn all of
fucking Gerrit, and then continue on Gerrit to finalise the patch, then we
should just kill PR now.

Instead we are going to have to have some people that participate in review on
GitHub. Which, fortunately, is very open and much like on Gerrit.

Anyone with a GitHub account can participate in review, anyone can take it and
submit it to Gerrit. The only minor detail is closing the PR. When that
happens and who that does. The who is clear, someone with write access to the
Wikimedia GitHub account. The when, could be when it is taken to Gerrit, could
be when it lands in master.

-- Krinkle

[1] Squash because on GitHub it is common to add commits and squash later
(some projects don't even squash, it depends on whether they handle a policy
where every commit in the master history should be good - either way, we do,
so when a PR gets a commit added to it that fixes a syntax error, we should
squash it in the process of preparing for Gerrit).


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

Re: [Wikitech-l] Seemingly proprietary Javascript

On 03/05/2013 09:47 AM, Isarra Yos wrote:
 The licensing information is on the page itself, of which the minified
 js winds up a part. For every file or other object that makes up the
 page to all contain the licensing information would be pretty unusual.
 
 It's like taking a file out of a page and then complaining that it has
 no licensing information when said information was in the page text
 right under it.

What licensing information are you referring to?

Of course, the code is not under the content license (content license
being CC-BY-SA currently for Wikimedia).

Matt Flaschen

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

Re: [Wikitech-l] Github/Gerrit mirroring

2013-03-05 Thread Chad

There's some upstream developers working on a github plugin. I was going to
mention it once there was something worth showing (which there isn't yet).

-Chad
On Mar 5, 2013 9:39 AM, Jon Robson jdlrob...@gmail.com wrote:

 I was wondering what the latest on this was (I can't seem to find any
 recent updates in my mailing list). The MobileFrontend project was
 reassured to see a github user commenting on our commits in github.
 It's made me more excited about a universe where pull requests made in
 github show up in gerrit and can be merged. How close to this dream
 are we?

 ___
 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] Seemingly proprietary Javascript

On Tue, Mar 5, 2013 at 2:11 PM, Jay Ashworth j...@baylink.com wrote:

 I am neither an engineer, nor a WMF staffer, but I want to throw a flag
 here anyway.

 Yes, it will cause an issue.  If that extra data is going in every reply,
 multiply its size by our replies per day count, won't you?  I don't know
 what that number is, but I'm quite certain it's substantial.

 *Every single byte* that goes in a place where it will be included in every
 reply directly affects our 95%ile data transfer, I should think, and thus
 our budget.  Bytes are not always free.


True, but if it's legally required it's not like we have an option.

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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread James Forrester

On 5 March 2013 11:55, Matthew Flaschen mflasc...@wikimedia.org wrote:

 On 03/05/2013 09:47 AM, Isarra Yos wrote:
  The licensing information is on the page itself, of which the minified
  js winds up a part. For every file or other object that makes up the
  page to all contain the licensing information would be pretty unusual.
 
  It's like taking a file out of a page and then complaining that it has
  no licensing information when said information was in the page text
  right under it.

 What licensing information are you referring to?

 Of course, the code is not under the content license (content license
 being CC-BY-SA currently for Wikimedia).


I think the point is that
https://upload.wikimedia.org/wikipedia/commons/4/48/Magnolia_%C3%97_soulangeana_blossom.jpgdoesn't
have any licence information in it either, though
https://commons.wikimedia.org/wiki/File:Magnolia_%C3%97_soulangeana_blossom.jpgdoes,
and this is analogous to the output of load.php not having licensing
information in it, but the composited page having it.

(And licensing of Gadgets is a complete mess, but that's somewhat
orthogonal to the point.)

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

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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Jay Ashworth

- Original Message -
 From: Tyler Romeo tylerro...@gmail.com

  Yes, it will cause an issue. If that extra data is going in every
  reply,
  multiply its size by our replies per day count, won't you? I don't
  know
  what that number is, but I'm quite certain it's substantial.
 
  *Every single byte* that goes in a place where it will be included
  in every
  reply directly affects our 95%ile data transfer, I should think, and
  thus
  our budget. Bytes are not always free.
 
 True, but if it's legally required it's not like we have an option.

Certainly.  But I see no reason to think it's legally required.  And
while I, too, only play one on the Internet, I've been doing it since 1983.

And I haven't been surprised all that often.

Mr Villa will come up with a more researched decision, certainly, but I
am relatively certain that a defensible case can be made that minifying is
equivalent to compiling, for the purposes of the license.

And in the unlikely event that's not good enough, the Foundation may well
be able to get a codicil license on the relevant libraries, acknowledging
that it needn't include the license text in on-the-wire minified copies.

My personal opinion, though, is that the proper approach is that the
license be officially interpreted by its issuer to exempt this sort
of minification-caused potential violation, as otherwise, minification
will negatively affect everyone who uses it, many of whom haven't WMF's
budget.

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth  Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

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

Re: [Wikitech-l] Seemingly proprietary Javascript

On Tue, Mar 5, 2013 at 3:08 PM, Jay Ashworth j...@baylink.com wrote:

 Certainly.  But I see no reason to think it's legally required.  And
 while I, too, only play one on the Internet, I've been doing it since 1983.


If you read the licenses, it's pretty obvious. Also, popular libraries
(such as Google's hosted versions of jQuery and others) always include
license headers in the minified versions.

And in the unlikely event that's not good enough, the Foundation may well
 be able to get a codicil license on the relevant libraries, acknowledging
 that it needn't include the license text in on-the-wire minified copies.


But WMF getting a license doesn't help everybody else who uses MW.

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

Re: [Wikitech-l] Reminder about the best way to link to bugs in commits

2013-03-05 Thread Nischay Nahata

On Mon, Mar 4, 2013 at 7:06 AM, Quim Gil q...@wikimedia.org wrote:

 fwiw this is not a discussion about Gerrit features but about git commit
 and code contribution good practices in general. There is plenty of
 literature out there.


  I also prefer it in the header. The bug report is the best description :)


 A bug report is supposed to describe a problem while the title of a commit
 message is supposed to describe the solution implemented.

 Plus you are limited to 50 chars. The bug number will take 5, that leaves
 you less than 45.

 Plus quite frequently a bug is fixed through more than one commit, and
 still you are supposed to explain in each commit message what you are doing
 in that commit.



I like to know about the problem before the solution implemented, that
saves me some time to think what solutions could be possible.
But that doesn't mean it always have to be in the header. It matters from
the point of view, looking like a bug fixer you are more concerned with bug
numbers while other people are concerned about what is implemented.

But what I find more important is see the bug numbers in the Gerrit 'view',
its easy to find the change for a particular bug being solved. Having a
separate column (as Erik suggested) for that would be the best solution :)




  Is it not possible for Gerrit to search if its in the header?


 Is this helpful?

 status:merged message:yourString

 http://stackoverflow.com/**questions/14409413/searching-**
 gerrit-by-commit-messagehttp://stackoverflow.com/questions/14409413/searching-gerrit-by-commit-message



  Tools should be coded around people. Not the other way around.


 Agree. A 100% human readable commit message title describing what a commit
 does feels more human than Fixes Bug 12345 + truncated bug description


  Is there another software project that uses the summary line
 in a similar way to MediaWiki?


 That was the best question of this thread. I have done some research, and
 the guidelines I found mentioning the inclusion of bug numbers in commit
 messages pointed all to a specific bug line after the commit description
 and an empty line - which is in line with our guidelines. Gerrit and other
 Git tools understand that line as metadata and you can do good things with
 it (as we are on our way of doing between Gerrit and Bugzilla):

 OpenStack Git Commit Good Practice
 https://wiki.openstack.org/**wiki/GitCommitMessageshttps://wiki.openstack.org/wiki/GitCommitMessages

 Chromium - Contributing code
 http://www.chromium.org/**developers/contributing-codehttp://www.chromium.org/developers/contributing-code

 Qt - Introduction to Gerrit
 http://qt-project.org/wiki/**Gerrit-Introductionhttp://qt-project.org/wiki/Gerrit-Introduction

 GNOME - a guide to writing git commit messages
 http://blogs.gnome.org/danni/**2011/10/25/a-guide-to-writing-**
 git-commit-messages/http://blogs.gnome.org/danni/2011/10/25/a-guide-to-writing-git-commit-messages/

 EGit - Contributor Guide
 http://wiki.eclipse.org/EGit/**Contributor_Guidehttp://wiki.eclipse.org/EGit/Contributor_Guide

 Gerrit Code Review - Contributing
 https://gerrit-review.**googlesource.com/**Documentation/dev-**
 contributing.htmlhttps://gerrit-review.googlesource.com/Documentation/dev-contributing.html

 Proper Git Commit Messages and an Elegant Git History
 http://ablogaboutcode.com/**2011/03/23/proper-git-commit-**
 messages-and-an-elegant-git-**history/http://ablogaboutcode.com/2011/03/23/proper-git-commit-messages-and-an-elegant-git-history/


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

 __**_
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Cheers,

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

Re: [Wikitech-l] Seemingly proprietary Javascript



 But WMF getting a license doesn't help everybody else who uses MW.


That would depend on the type of license the wmf got.

But hopefully it wouldn't come to that, as quite frankly that would be
insane.

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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Jay Ashworth

- Original Message -
 From: Tyler Romeo tylerro...@gmail.com

 But WMF getting a license doesn't help everybody else who uses MW.

Minification is a WMF cluster issue, not a MW software issue, is it not?

Cheers,
-- jra
-- 
Jay R. Ashworth  Baylink   j...@baylink.com
Designer The Things I Think   RFC 2100
Ashworth  Associates http://baylink.pitas.com 2000 Land Rover DII
St Petersburg FL USA   #natog  +1 727 647 1274

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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Luke Welling WMF

We should discuss them separately, but this core mediawiki JS is GPL2
https://github.com/wikimedia/mediawiki-core/tree/master/resources

This JS which was mentioned in the forwarded email that started this
discussion is available via a wiki page so is probably under a CC-BY-SA-3.0
as it is submitted, edited and accessed like content.
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_User_scripts/Scripts#Scripts

Luke


On Tue, Mar 5, 2013 at 2:55 PM, Matthew Flaschen mflasc...@wikimedia.orgwrote:

 On 03/05/2013 09:47 AM, Isarra Yos wrote:
  The licensing information is on the page itself, of which the minified
  js winds up a part. For every file or other object that makes up the
  page to all contain the licensing information would be pretty unusual.
 
  It's like taking a file out of a page and then complaining that it has
  no licensing information when said information was in the page text
  right under it.

 What licensing information are you referring to?

 Of course, the code is not under the content license (content license
 being CC-BY-SA currently for Wikimedia).

 Matt Flaschen

 ___
 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] Seemingly proprietary Javascript

On 2013-03-05 4:28 PM, Jay Ashworth j...@baylink.com wrote:

 - Original Message -
  From: Tyler Romeo tylerro...@gmail.com

  But WMF getting a license doesn't help everybody else who uses MW.

 Minification is a WMF cluster issue, not a MW software issue, is it not?

 Cheers,
 -- jra
 --
 Jay R. Ashworth  Baylink
j...@baylink.com
 Designer The Things I Think   RFC
2100
 Ashworth  Associates http://baylink.pitas.com 2000 Land
Rover DII
 St Petersburg FL USA   #natog  +1 727 647
1274

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

Mediawiki minifies things regardless of if its being run by the WMF or
somebody else.

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

Re: [Wikitech-l] Seemingly proprietary Javascript

On 03/05/2013 12:29 PM, Luke Welling WMF wrote:
 We should discuss them separately, but this core mediawiki JS is GPL2
 https://github.com/wikimedia/mediawiki-core/tree/master/resources

I am referring to Isarra's comment:

The licensing information is on the page itself, of which the minified
js winds up a part.

As far as I can tell, that is not true for the *code* license(s) for
core and extensions.

Matt Flaschen

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

Re: [Wikitech-l] Seemingly proprietary Javascript

On 03/05/2013 12:08 PM, Jay Ashworth wrote:
 And in the unlikely event that's not good enough, the Foundation may well
 be able to get a codicil license on the relevant libraries, acknowledging
 that it needn't include the license text in on-the-wire minified copies.

If it does turn out we legally *need* more license
preservation/disclosure, we should add more license preservation.

Getting a special get out of jail free card for WMF only is not
acceptable.  Our sites run free software, software that anyone can also
run under the same (free) licenses.

It may also not be realistic (many authors probably would not
cooperate).  But it's something we shouldn't even ask for.

Matt Flaschen

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

Re: [Wikitech-l] Seemingly proprietary Javascript

On 03/05/2013 12:27 PM, Jay Ashworth wrote:
 - Original Message -
 From: Tyler Romeo tylerro...@gmail.com
 
 But WMF getting a license doesn't help everybody else who uses MW.
 
 Minification is a WMF cluster issue, not a MW software issue, is it not?

No, ResourceLoader and the minification is part of MW core.

Matt Flaschen

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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread vitalif

I would just like to note that while it may be silly or useless 
to

insert licenses into minified JavaScript, it is nonetheless *legally
required* to do so, regardless of the technical aspect of it.


My 2 points - during my own research about free licenses, I've decided 
that for JS, a good license is MPL 2.0: http://www.mozilla.org/MPL/2.0/


Its advantages are:
1) It's strong file-level copyleft. File-level is good for JS, 
because it eliminates any problems of deciding whether a *.js file is or 
is not a part of a derivative work, and any problems of using together 
with differently licensed JS.
2) It's explicitly compatible with GPLv2+, LGPLv2.1+ or AGPLv3+. 
Incompatibility problem of MPL 1.1 caused triple licensing of Firefox 
(GPL/LGPL/MPL).
3) It does not require you to include long notices into every file. You 
only must inform recipients that the Source Code Form of the Covered 
Software is governed by the terms of this License, and how they can 
obtain a copy of this License. You may even not include any notice in 
files themselves provided that you include it in some place where a 
recipient would be likely to look for such a notice.


Also, what I've understood also was that CC-BY-SA is not good for 
source code at all, at least because it's incompatible with GPL. So 
CC-BY-SA licensed JS may be a problem.


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

[Wikitech-l] Using test doubles to test code with external dependencies

2013-03-05 Thread Ori Livneh

A short while ago I wrote a set of three PHP unit tests for Math that use test 
doubles to stub out external dependencies (in this case, the database-backed 
cache and the texvc executable). My intent was to demonstrate the technique to 
another developer, so I commented the code extensively. It occurred to me that 
other people might be interested, too, so I'm sharing it here.

The advantage of such tests is that they typically faster and far less brittle 
than tests that rely on external resources. They also make test results less 
noisy: if the test fails, you know that it's because your code was wrong, and 
not because the database happened to suffer an outage. Finally, they are more 
portable, because they don't require that you configure external dependencies 
to make them work.

If you are interested, check out the example, and the relevant chapter in the 
PHPUnit docs.

https://gerrit.wikimedia.org/r/#/c/49612/1/tests/MathTexvcTest.php

http://www.phpunit.de/manual/current/en/test-doubles.html 

--
Ori Livneh



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

[Wikitech-l] Query profiling for features developers

2013-03-05 Thread Steven Walling

Hey all,

Just wanted to share this piece of new documentation with everyone:
https://wikitech.wikimedia.org/wiki/Query_profiling_for_features_developers

This came out of a discussion about queries we need to run for the next
iteration of Extension:GettingStarted by Ori, Matt Flaschen, and S Page.

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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Ryan Kaldari


On 3/5/13 1:03 PM, vita...@yourcmc.ru wrote:

I would just like to note that while it may be silly or useless to
insert licenses into minified JavaScript, it is nonetheless *legally
required* to do so, regardless of the technical aspect of it.


My 2 points - during my own research about free licenses, I've decided 
that for JS, a good license is MPL 2.0: http://www.mozilla.org/MPL/2.0/


I license all of my MediaWiki extensions under an MIT license since I 
want people to be able to reuse the JS code on-wiki, but some people 
have claimed that even MIT isn't compatible with CC-BY-SA [1]. I've been 
thinking about switching to CC-Zero instead. It's funny how most free 
software is so burdened with inane incompatible restrictions that we 
can't legally use it in many situations. What do people think about 
using CC-Zero as a license? Now that's free software!


1. 
https://en.wikipedia.org/wiki/Wikipedia_talk:Copyrights/Archive_15#CC_BY-SA_compatibility


Ryan Kaldari

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

Re: [Wikitech-l] Seemingly proprietary Javascript

On Tue, Mar 5, 2013 at 5:01 PM, Ryan Kaldari rkald...@wikimedia.org wrote:

 I license all of my MediaWiki extensions under an MIT license since I want
 people to be able to reuse the JS code on-wiki, but some people have
 claimed that even MIT isn't compatible with CC-BY-SA [1]. I've been
 thinking about switching to CC-Zero instead. It's funny how most free
 software is so burdened with inane incompatible restrictions that we can't
 legally use it in many situations. What do people think about using CC-Zero
 as a license? Now that's free software!


I'm not sure that's true at all. The MIT license is pretty much a proper
subset of CC-BY-SA, i.e., it has less restrictions and the restrictions it
has are in CC-BY-SA anyway. People are lying to you. ;)

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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread David Gerard

On 5 March 2013 22:08, Tyler Romeo tylerro...@gmail.com wrote:
 On Tue, Mar 5, 2013 at 5:01 PM, Ryan Kaldari rkald...@wikimedia.org wrote:

 I license all of my MediaWiki extensions under an MIT license since I want
 people to be able to reuse the JS code on-wiki, but some people have
 claimed that even MIT isn't compatible with CC-BY-SA [1]. I've been
 thinking about switching to CC-Zero instead. It's funny how most free
 software is so burdened with inane incompatible restrictions that we can't
 legally use it in many situations. What do people think about using CC-Zero
 as a license? Now that's free software!

 I'm not sure that's true at all. The MIT license is pretty much a proper
 subset of CC-BY-SA, i.e., it has less restrictions and the restrictions it
 has are in CC-BY-SA anyway. People are lying to you. ;)


People will say any spurious bollocks in a licence discussion. (You've
been on Commons, right?) This is why we have proper lawyers on hand
:-)

I appreciate it would be *nice* to put the licence in the JS, Mako
makes the point as nicely in the bug as the original poster didn't in
this thread. But there must be a method that isn't operationally
insane.


- d.

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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread MZMcBride

Ryan Kaldari wrote:
What do people think about using CC-Zero as a license? Now that's free
software!

The Open Source Initiative doesn't seem to really like the idea:
http://opensource.org/faq#cc-zero.

A number of former and current contributors (notably Lee Daniel Crocker)
have released their creative works and inventions into the public domain:
https://en.wikipedia.org/wiki/User:Lee_Daniel_Crocker.

I've always found CC-Zero and its surrounding arguments to be pretty
stupid. I release most of the code I write into the public domain (though
most of it lacks sufficient creativity in any case).

MZMcBride



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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Platonides

On 05/03/13 14:07, Alexander Berntsen wrote:
 On 05/03/13 13:18, Max Semenik wrote:
 If you mean that we have to insert that huge chunk of comments from
  [1] into every page, the answer is no because we'll have to
 include several licenses here, making it ridiculously long.
 Please see the JavaScript Web Labels section of the article[0]. Is this
 a possibility?

http://www.gnu.org/licenses/javascript-labels.html

Yes, it would be. I expect the generated page to be insanely huge, but
if LibreJS loads a page so big that blocks your browser, it's not our
fault at all :)

I see however that it tries to confirm that the source js matches the
minified version, which may be quite hard.


Furthermore, the resourceloader can multiple modules in one request,
producing apparently different urls, so if we had to create all possible
urls, expect a factorial growth.


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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Greg Grossmeier

quote name=Ryan Kaldari date=2013-03-05 time=14:01:42 -0800
 What do people think about using CC-Zero as a license?
 Now that's free software!

Relevant link for those interested in more background:
https://creativecommons.org/weblog/entry/27081

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

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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Max Semenik

On 06.03.2013, 2:01 Ryan wrote:

 I license all of my MediaWiki extensions under an MIT license since I
 want people to be able to reuse the JS code on-wiki, but some people 
 have claimed that even MIT isn't compatible with CC-BY-SA [1]. I've been
 thinking about switching to CC-Zero instead. It's funny how most free
 software is so burdened with inane incompatible restrictions that we 
 can't legally use it in many situations. What do people think about 
 using CC-Zero as a license? Now that's free software!

 1. 
 https://en.wikipedia.org/wiki/Wikipedia_talk:Copyrights/Archive_15#CC_BY-SA_compatibility

My extensions are WTFPL;)


-- 
Best regards,
  Max Semenik ([[User:MaxSem]])


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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Platonides

On 05/03/13 21:53, Matthew Flaschen wrote:
 On 03/05/2013 12:29 PM, Luke Welling WMF wrote:
 We should discuss them separately, but this core mediawiki JS is GPL2
 https://github.com/wikimedia/mediawiki-core/tree/master/resources
 
 I am referring to Isarra's comment:
 
 The licensing information is on the page itself, of which the minified
 js winds up a part.
 
 As far as I can tell, that is not true for the *code* license(s) for
 core and extensions.
 
 Matt Flaschen

Did you look at http://en.wikipedia.org/w/COPYING ?



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

Re: [Wikitech-l] Seemingly proprietary Javascript

On 2013-03-05 6:29 PM, MZMcBride z...@mzmcbride.com wrote:

 Ryan Kaldari wrote:
 What do people think about using CC-Zero as a license? Now that's free
 software!

 The Open Source Initiative doesn't seem to really like the idea:
 http://opensource.org/faq#cc-zero.

 A number of former and current contributors (notably Lee Daniel Crocker)
 have released their creative works and inventions into the public domain:
 https://en.wikipedia.org/wiki/User:Lee_Daniel_Crocker.

 I've always found CC-Zero and its surrounding arguments to be pretty
 stupid. I release most of the code I write into the public domain (though
 most of it lacks sufficient creativity in any case).

 MZMcBride



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

I wonder how osi would feel about https://github.com/avar/DWTFYWWI license.

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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Petr Onderka

On Tue, Mar 5, 2013 at 9:16 PM, Tyler Romeo tylerro...@gmail.com wrote:
 Also, popular libraries
 (such as Google's hosted versions of jQuery and others) always include
 license headers in the minified versions.

That's not what I see.
If I look at jQuery as hosted by Google [1], it starts with the
following comment (and nothing more):

/*! jQuery v1.9.1 | (c) 2005, 2012 jQuery Foundation, Inc. |
jquery.org/license //@ sourceMappingURL=jquery.min.map */

It does link to a license (though it doesn't even mention what the
license is directly),
but it certainly doesn't contain the whole license itself.
And, as I understand it, that's what you claim is required and
what others claim would be a waste of bandwidth

[1]: http://ajax.googleapis.com/ajax/libs/jquery/1.9.1/jquery.min.js

Petr Onderka
[[en:User:Svick]]

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

Re: [Wikitech-l] Seemingly proprietary Javascript

On 03/05/2013 02:33 PM, Platonides wrote:
 On 05/03/13 21:53, Matthew Flaschen wrote:
 On 03/05/2013 12:29 PM, Luke Welling WMF wrote:
 We should discuss them separately, but this core mediawiki JS is GPL2
 https://github.com/wikimedia/mediawiki-core/tree/master/resources

 I am referring to Isarra's comment:

 The licensing information is on the page itself, of which the minified
 js winds up a part.

 As far as I can tell, that is not true for the *code* license(s) for
 core and extensions.

 Matt Flaschen
 
 Did you look at http://en.wikipedia.org/w/COPYING ?

Do you really expect people to find that?

We're basically talking about what is visible in the binary version of
the site.

We all know they can get license information from the source by doing
git clones.

I don't think it's realistic that people will successfully guess they
can visit that /w/COPYING url.  And not all the code is under GPLv2
anyway, though it should all be free on WMF sites.

Matt Flaschen

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

Re: [Wikitech-l] Query profiling for features developers

2013-03-05 Thread Quim Gil


On 03/05/2013 01:44 PM, Steven Walling wrote:

Just wanted to share this piece of new documentation with everyone:
https://wikitech.wikimedia.org/wiki/Query_profiling_for_features_developers


Thank you for improving our documentation.

Is there any reason not to have this content at mediawiki.org linked 
with the rest of developer docs?


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

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

Re: [Wikitech-l] Query profiling for features developers

On 03/05/2013 04:27 PM, Quim Gil wrote:
 On 03/05/2013 01:44 PM, Steven Walling wrote:
 Just wanted to share this piece of new documentation with everyone:
 https://wikitech.wikimedia.org/wiki/Query_profiling_for_features_developers

 
 Thank you for improving our documentation.
 
 Is there any reason not to have this content at mediawiki.org linked
 with the rest of developer docs?

I think this is a border-line case.  Some of it (e.g. the parts about
production slaves and Graphite) mainly applies to the WMF cluster.

I've added a soft redirect at
https://www.mediawiki.org/wiki/Query_profiling_for_features_developers
though.

Matt Flaschen

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

Re: [Wikitech-l] Seemingly proprietary Javascript

2013-03-05 Thread Antoine Musso

Le 05/03/13 14:28, MZMcBride a écrit :
 A number of former and current contributors (notably Lee Daniel Crocker)
 have released their creative works and inventions into the public domain:
 https://en.wikipedia.org/wiki/User:Lee_Daniel_Crocker.

Does that include is work on the OCaml tool that generate the math
rendering?  I am wondering if the rendering result would end up being PD
too.

-- 
Antoine hashar Musso


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

[Wikitech-l] Linking from Wikipedia articles to local library resources

2013-03-05 Thread Sumana Harihareswara

See http://lists.wikimedia.org/pipermail/glam/2013-March/000361.html 
http://everybodyslibraries.com/2013/03/04/from-wikipedia-to-our-libraries/
: how do we get people from Wikipedia articles to the related offerings
of our local libraries?

http://en.wikipedia.org/wiki/Template:Library_resources_box create a
sidebar box with links to resources about (or by) the topic of  a
Wikipedia article in a reader’s library, or in another library a reader
might want to consult.

And more!

As with most things related to Wikipedia, this service is experimental,
and subject to change (and, hopefully, improvement) over time.  I’d love
to hear thoughts and suggestions from users and maintainers of Wikipedia
and libraries.

John, since you said you're new to template-building, you might enjoy
learning about what the new Lua templating system gives you:
https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual

-- 
Sumana Harihareswara
Engineering Community Manager
Wikimedia Foundation

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

Re: [Wikitech-l] Seemingly proprietary Javascript

On 2013-03-05 9:17 PM, Antoine Musso hashar+...@free.fr wrote:

 Le 05/03/13 14:28, MZMcBride a écrit :
  A number of former and current contributors (notably Lee Daniel Crocker)
  have released their creative works and inventions into the public
domain:
  https://en.wikipedia.org/wiki/User:Lee_Daniel_Crocker.

 Does that include is work on the OCaml tool that generate the math
 rendering?  I am wondering if the rendering result would end up being PD
 too.

 --
 Antoine hashar Musso


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

The ocaml tool does security verification from what I understand. The
actual rendering is done by TeX.(I think) Also I didnt think the license of
a tool extended to its output. I can make non gpl images in the gimp, etc

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

Re: [Wikitech-l] QUnit testing in Jenkins

On 03/04/2013 07:12 PM, Krinkle wrote:
 Things this will catch are basically everything else. Any runtime error
 that we can't detect in static analysis but will fail no matter what
 browser you're in, such as:
 
 * misspelled identifiers or syntax errors
 * issues with ResourceLoader (mw.loader)
 * issues with AJAX
 * any code failures that result in exceptions
 * the obvious (catching failures/regressions in our QUnit tests)

This is really a great step forward.

Thanks,

Matt Flaschen

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

Re: [Wikitech-l] Global user CSS and JS

On 03/05/2013 09:27 AM, James Forrester wrote:
 You can of course always counter-over-ride your global JS/CSS locally - the
 composite rule would presumably be changed to:
 
 1. file,
 2. site
 3. skin,
 *. global-user
 4. local-user

However, it's trickier to override JS then override CSS.  For example,
you can't remove a single event listener unless you have a reference to
the original function.

Matt Flaschen

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

Re: [Wikitech-l] Linking from Wikipedia articles to local library resources

On 2013-03-05 9:20 PM, Sumana Harihareswara suma...@wikimedia.org wrote:

 See http://lists.wikimedia.org/pipermail/glam/2013-March/000361.html 
 http://everybodyslibraries.com/2013/03/04/from-wikipedia-to-our-libraries/
 : how do we get people from Wikipedia articles to the related offerings
 of our local libraries?

 http://en.wikipedia.org/wiki/Template:Library_resources_box create a
 sidebar box with links to resources about (or by) the topic of  a
 Wikipedia article in a reader’s library, or in another library a reader
 might want to consult.

 And more!

 As with most things related to Wikipedia, this service is experimental,
 and subject to change (and, hopefully, improvement) over time.  I’d love
 to hear thoughts and suggestions from users and maintainers of Wikipedia
 and libraries.

 John, since you said you're new to template-building, you might enjoy
 learning about what the new Lua templating system gives you:
 https://www.mediawiki.org/wiki/Extension:Scribunto/Lua_reference_manual

 --
 Sumana Harihareswara
 Engineering Community Manager
 Wikimedia Foundation

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

Sounds like the use case of special:booksources page...

offtopic rant

The problem with libraries electronic resources (or at least my libraries')
is not that people are too google addicted to consider them. The problem is
that they are a usability nightmere. In one case I recall I was not able to
download more than 10 pages at a time or effectively navigate because the
interface was a horrid mess. People go where they can get what they need in
the easiest fashion. Libraries are not even close to providing that for
electronic resources. Otoh I love me my dead tree books, and libraries are
still king there.

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

Re: [Wikitech-l] Problem with CentralAuth in MobileFrontend

2013-03-05 Thread Jon Robson

So an update. I'm pretty sure I've worked this out. CentralAuth will only
work if the user has previously visited the wiki project the login attempt
is made for. Many browsers these days refuse cookies for sites the user has
not visited. I'm still investigating but I'm pretty sure an image to a URL
counts as a previous visit.
On 28 Feb 2013 13:07, Juliusz Gonera jgon...@wikimedia.org wrote:

 On 02/27/2013 05:13 PM, Paul Selitskas wrote:

 Do you use the same protocol in Wikipedia and other projects? When I
 first log in via HTTPS and then somehow get to HTTP, I need to log in.


 We use the same protocol. We enforce HTTPS after login, and later use
 protocol agnostic URLs.

 --
 Juliusz

 __**_
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/**mailman/listinfo/wikitech-lhttps://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] Seemingly proprietary Javascript

2013-03-05 Thread MZMcBride

Antoine Musso wrote:
Le 05/03/13 14:28, MZMcBride a écrit :
 A number of former and current contributors (notably Lee Daniel Crocker)
 have released their creative works and inventions into the public
domain: https://en.wikipedia.org/wiki/User:Lee_Daniel_Crocker.

Does that include is work on the OCaml tool that generate the math
rendering?  I am wondering if the rendering result would end up being PD
too.

Sorry, I have no idea. You'd have to ask Lee, I suppose. I think he's
still around.

Generated math expressions fall outside of (U.S.) copyright, as I
understand it, though. At least the majority of them. I don't imagine you
could argue that math2+2=4/math is sufficiently creative to warrant
copyright. Though perhaps more advanced math would qualify.

All that said, I don't think Lee has the authority to release (or not
release) any possible copyright on generated math expressions. A piano
maker surely can't release the copyright on the works of a pianist

This is why I just release everything into the public domain and flee. ;-)

MZMcBride



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

Re: [Wikitech-l] Problem with CentralAuth in MobileFrontend

From what I *understand* you don't have an account on the local wiki until
you visit there. Could perhaps whatever api methods used by the app not be
triggering this auto-account-creation process properly like a normal web
interface edit would?

-bawolff
On 2013-03-05 11:17 PM, Jon Robson jdlrob...@gmail.com wrote:

 So an update. I'm pretty sure I've worked this out. CentralAuth will only
 work if the user has previously visited the wiki project the login attempt
 is made for. Many browsers these days refuse cookies for sites the user has
 not visited. I'm still investigating but I'm pretty sure an image to a URL
 counts as a previous visit.
 On 28 Feb 2013 13:07, Juliusz Gonera jgon...@wikimedia.org wrote:

  On 02/27/2013 05:13 PM, Paul Selitskas wrote:
 
  Do you use the same protocol in Wikipedia and other projects? When I
  first log in via HTTPS and then somehow get to HTTP, I need to log in.
 
 
  We use the same protocol. We enforce HTTPS after login, and later use
  protocol agnostic URLs.
 
  --
  Juliusz
 
  __**_
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
 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] Seemingly proprietary Javascript


On 05/03/13 23:45, Matthew Flaschen wrote:

On 03/05/2013 02:33 PM, Platonides wrote:

On 05/03/13 21:53, Matthew Flaschen wrote:

On 03/05/2013 12:29 PM, Luke Welling WMF wrote:

We should discuss them separately, but this core mediawiki JS is GPL2
https://github.com/wikimedia/mediawiki-core/tree/master/resources

I am referring to Isarra's comment:

The licensing information is on the page itself, of which the minified
js winds up a part.

As far as I can tell, that is not true for the *code* license(s) for
core and extensions.

Matt Flaschen

Did you look at http://en.wikipedia.org/w/COPYING ?

Do you really expect people to find that?

We're basically talking about what is visible in the binary version of
the site.

We all know they can get license information from the source by doing
git clones.

I don't think it's realistic that people will successfully guess they
can visit that /w/COPYING url.  And not all the code is under GPLv2
anyway, though it should all be free on WMF sites.

Matt Flaschen

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


Alternately, it's the same as how people can find the license of any of 
it from the front ('binary') end. The content is specified in the footer 
and there is a link to mediawiki for platform information, and the 
resulting javascript is a combination of both of those...


But I guess my point was more that I just find it a little strange that 
folks would be taking javascript out of that context when such would 
never be done with other pieces of a page like images, which have a 
similar process to find their copyright information and yet tend to 
perhaps be more meaningful out of context than the js.


Although if such images needed to have licensing included in their file 
headers as well, while that would result in a complete ruddy mess, it 
might actually prove useful to reusers.


--
-— Isarra


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

Re: [Wikitech-l] Problem with CentralAuth in MobileFrontend

2013-03-05 Thread Yuri Astrakhan

Just for the record, sorry for not posting it right away:

Chris Steipp found the issue in my case to be the enabled Block
third-party cookies and site data chrome setting. Even though this is not
default at the moment, apparently Firefox is thinking of making this a
default. Enabling it breaks the cross site family logins (but not
cross-language) logins.


On Tue, Mar 5, 2013 at 10:45 PM, Brian Wolff bawo...@gmail.com wrote:

 From what I *understand* you don't have an account on the local wiki until
 you visit there. Could perhaps whatever api methods used by the app not be
 triggering this auto-account-creation process properly like a normal web
 interface edit would?

 -bawolff
 On 2013-03-05 11:17 PM, Jon Robson jdlrob...@gmail.com wrote:

  So an update. I'm pretty sure I've worked this out. CentralAuth will only
  work if the user has previously visited the wiki project the login
 attempt
  is made for. Many browsers these days refuse cookies for sites the user
 has
  not visited. I'm still investigating but I'm pretty sure an image to a
 URL
  counts as a previous visit.
  On 28 Feb 2013 13:07, Juliusz Gonera jgon...@wikimedia.org wrote:
 
   On 02/27/2013 05:13 PM, Paul Selitskas wrote:
  
   Do you use the same protocol in Wikipedia and other projects? When I
   first log in via HTTPS and then somehow get to HTTP, I need to log in.
  
  
   We use the same protocol. We enforce HTTPS after login, and later use
   protocol agnostic URLs.
  
   --
   Juliusz
  
   __**_
   Wikitech-l mailing list
   Wikitech-l@lists.wikimedia.org
   https://lists.wikimedia.org/**mailman/listinfo/wikitech-l
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
  ___
  Wikitech-l mailing list
  Wikitech-l@lists.wikimedia.org
  https://lists.wikimedia.org/mailman/listinfo/wikitech-l
 ___
 Wikitech-l mailing list
 Wikitech-l@lists.wikimedia.org
 https://lists.wikimedia.org/mailman/listinfo/wikitech-l

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

Re: [Wikitech-l] Global user CSS and JS