Re: [Wikitech-l] jenkins-bot has submitted this change and it was merged.

[Andre Klapper]

On Sat, 2013-03-02 at 16:47 -0300, Helder . wrote:
> Can we get the "owner" instead of the "last reviewer" in the text
> below, when a change is merged?

Please file a request under the "Wikimedia" product in
https://bugzilla.wikimedia.org so this does not get lost.

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


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

[Wikitech-l] Replicating enwiki and dewiki for research purposes

[Andreas Nüßlein]

Hi list,

so I need to set up a local instance of the dewiki- and enwiki-DB with all
revisions.. :-D

I know it's rather a mammoth project so I was wondering if somebody could
give me some pointers?

First of all, I would need to know what kind of hardware I should get. Is
it possible/smart to have it all in two ginormous MySQL-Instance (one for
each of the languages) or will I need to do sharding?

I don't need it to run smoothly. I only need to be able to query the
database (and I know some of these queries can run for days)

I will probably have access to some rather powerful machines here at the
university and I have also quite a few workstation-machines on which I
could theoretically do the sharding.


Thanks in advance
Andreas



PS: If it helps: I'm living in Berlin and I will gladly also just have a
face-to-face meeting with anybody willing to share wisdom :)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] QUnit testing in Jenkins

[Željko Filipin]

On Tue, Mar 5, 2013 at 4:12 AM, Krinkle  wrote:

> As of today, we automatically run our QUnit test suite[4] in MediaWiki
> core from Jenkins.
>

Great news!


> I won't go in detail about what PhantomJS is, but in short:
>
> It is a "headless" WebKit browser. Meaning, it doesn't render pixels
> to a screen on the server side, but it does behave like a fully valid
> browser environment as if it were rendering it to a screen (CSS is
> being parsed, the DOM is there, stylesheets are active, retrieving
> computed styles, ajax requests can be made etc.).
> For more information, see [2].


PhantomJS can render pixels, but I am not sure if it does it by default, or
only when requested. The reason I know it can render pixels is that you can
take a screen shot while driving PhantomJS with Selenium. Screenshots from
a headless browser. Think about it for a minute. :)

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

Re: [Wikitech-l] QUnit testing in Jenkins

[Željko Filipin]

On Tue, Mar 5, 2013 at 4:12 AM, Krinkle  wrote:

> However, unlike php-checkstyle, our QUnit tests
> are actually passing
>

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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Seemingly proprietary Javascript

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

GNU LibreJS blocks several Javascript sources around Wikipedia. I was
sent to this list by Kirk Billund. My issue as well as Kirk's replies
follows. I hope you are okay to read it in this form.

03/05/2013 11:16 - Alexander Berntsen wrote:
 GNU LibreJs[0] reports that several of the Javascript sources
 embedded by different parts of Wikipedia are proprietary[1].
 Is this a conscious anti-social choice[2], or have you merely
 not set up your source files to properly show their
 licence[3]?
 
 If the latter is the case, please remedy this. If the former
 is the case... please remedy this. It is extremely
 important.[4] In any event I hope to get a reply, as the
 distinction is important to me.
 
 [0]  https://www.gnu.org/software/librejs/ [1]
 https://www.gnu.org/philosophy/categories.html#ProprietarySoftware

 
[2]  https://www.gnu.org/philosophy/javascript-trap.html
 [3]
 https://www.gnu.org/software/librejs/free-your-javascript.html

 
[4]  https://www.gnu.org/philosophy/why-free.html

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].
>>> 
>>> Additionally, our JavaScript is minified[6] so adding comments
>>> is not possible. If you have further concerns, you can either
>>> respond to me, email the general Wikimedia technical list[7] or
>>> a general Mediawiki help list[8].
>>> 
>>> 
>>> [1] https://www.mediawiki.org/wiki/MediaWiki [2]
>>> https://www.mediawiki.org/wiki/License [3]
>>> https://en.wikipedia.org/wiki/JQuery [4]
>>> https://en.wikipedia.org/wiki/MediaWiki:Common.js [5]
>>> https://en.wikipedia.org/wiki/Wikipedia:Copyrights [6]
>>> https://www.mediawiki.org/wiki/ResourceLoader [7]
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l [8]
>>> https://lists.wikimedia.org/mailman/listinfo/mediawiki-l

03/05/2013 11:16 - Alexander Berntsen wrote:
>> Is it not possible to insert the licence as part of your build 
>> process? What I do with compiled or minified Javascript is to
>> build everything, and then insert the licence to all files using
>> BASH.

On 05/03/13 12:41, Wikipedia information team wrote:
> Unfortunately I don't fully understand how the minification process
> works, so it would probably be better if you asked your question on
> our technical mailing list 
>  and
> someone there would be able to give you a more specific answer.
- -- 
Alexander
alexan...@plaimi.net
http://plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlE13WcACgkQRtClrXBQc7VRwAEAhJLHhlpssJIze/B9IJ1un9kT
/ze8DysWeQHBpoGeKCQBALbfVL+yLy74dAEmncPrT3FAPB4WPjUDfOg8A7Vo/pXm
=peks
-END PGP SIGNATURE-

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

Re: [Wikitech-l] Seemingly proprietary Javascript

[Max Semenik]

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. All JS run on
Wikimedia sites is free, and if some software believes otherwise, that
software needs to be fixed.


-
[1] http://www.gnu.org/software/librejs/free-your-javascript.html


On 05.03.2013, 15:56 Alexander wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256

> GNU LibreJS blocks several Javascript sources around Wikipedia. I was
> sent to this list by Kirk Billund. My issue as well as Kirk's replies
> follows. I hope you are okay to read it in this form.

> 03/05/2013 11:16 - Alexander Berntsen wrote:
> GNU LibreJs[0] reports that several of the Javascript sources
> embedded by different parts of Wikipedia are proprietary[1].
> Is this a conscious anti-social choice[2], or have you merely
> not set up your source files to properly show their
> licence[3]?
> 
> If the latter is the case, please remedy this. If the former
> is the case... please remedy this. It is extremely
> important.[4] In any event I hope to get a reply, as the
> distinction is important to me.
> 
> [0]  https://www.gnu.org/software/librejs/ [1]
> https://www.gnu.org/philosophy/categories.html#ProprietarySoftware
>
> 
> [2]  https://www.gnu.org/philosophy/javascript-trap.html
> [3]
> https://www.gnu.org/software/librejs/free-your-javascript.html
>
> 
> [4]  https://www.gnu.org/philosophy/why-free.html


-- 
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

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

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?

> All JS run on Wikimedia sites is free, and if some software
> believes otherwise, that software needs to be fixed.
Do you have ideas on how to fix it?


[0]  https://www.gnu.org/software/librejs/free-your-javascript.html
- -- 
Alexander
alexan...@plaimi.net
http://plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF4EAREIAAYFAlE17h0ACgkQRtClrXBQc7XAaAEAqklgvLuiZMts0H2/T0oloJiL
Cpfn3KXFdvh04ihp+Y0A/jzm281pemFHmwRaPNLutEVYoeUhvoRvo3rIGE02nX4E
=dHAX
-END PGP SIGNATURE-

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

Re: [Wikitech-l] jenkins-bot has submitted this change and it was merged.

[Helder .]

Done.
https://bugzilla.wikimedia.org/show_bug.cgi?id=45738

Helder

On Tue, Mar 5, 2013 at 6:43 AM, Andre Klapper wrote:

> On Sat, 2013-03-02 at 16:47 -0300, Helder . wrote:
> > Can we get the "owner" instead of the "last reviewer" in the text
> > below, when a change is merged?
>
> Please file a request under the "Wikimedia" product in
> https://bugzilla.wikimedia.org so this does not get lost.
>
> andre
> --
> Andre Klapper | Wikimedia Bugwrangler
> http://blogs.gnome.org/aklapper/
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Seemingly proprietary Javascript

[David Gerard]

On 5 March 2013 11:56, Alexander Berntsen  wrote:

> 03/05/2013 11:16 - Alexander Berntsen wrote:
> GNU LibreJs[0] reports that several of the Javascript sources
> embedded by different parts of Wikipedia are proprietary[1].
> Is this a conscious anti-social choice[2], or have you merely
> not set up your source files to properly show their
> licence[3]?


Yeah, calling people antisocial when you ask them for something is
definitely the approach to take. Let us know how it works out for GNU
LibreJS.


- d.

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

Re: [Wikitech-l] Seemingly proprietary Javascript

[Alexander Berntsen]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 05/03/13 14:38, David Gerard wrote:
> Yeah, calling people antisocial when you ask them for something is 
> definitely the approach to take. Let us know how it works out for
> GNU LibreJS.
I did not call anyone antisocial. Furthermore I am not affiliated with
GNU LibreJS.
- -- 
Alexander
alexan...@plaimi.net
http://plaimi.net/~alexander
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iF0EAREIAAYFAlE19jwACgkQRtClrXBQc7VeUQEAsA4negyyHjMk6954Q4I6SJSp
gKleJiqwcT+ER24DTtoA+K1F7CGSmfVanYT0l0AYiQthigpCdewH7m1xPJGdrDE=
=WSU4
-END PGP SIGNATURE-

___
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

[Paul Selitskas]

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 wrote:

> On 4 March 2013 14:59, Krenair  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
>



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

Re: [Wikitech-l] Seemingly proprietary Javascript

[Helder .]

On Tue, Mar 5, 2013 at 8:56 AM, Alexander Berntsen  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

Helder

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

Re: [Wikitech-l] Replicating enwiki and dewiki for research purposes

[Quim Gil]

On 03/05/2013 02:54 AM, Andreas Nüßlein wrote:

Hi list,

so I need to set up a local instance of the dewiki- and enwiki-DB with all
revisions.. :-D


Just in case:
http://meta.wikimedia.org/wiki/Mirroring_Wikimedia_project_XML_dumps

Also, you might want to ask / discuss at

https://lists.wikimedia.org/mailman/listinfo/offline-l

Good luck with this interesting project!

--
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] Replicating enwiki and dewiki for research purposes

[Maria Miteva]

Hi,

You might also try the following mailing list:
* XML Data Dumps mailing
list
 *

Here is some info on importing XML dumps ( not sure what tools work well
but probably the mailing list can help with that)
http://meta.wikimedia.org/wiki/Data_dumps/Tools_for_importing

Also, Ariel Glenn recently announced two new tools for importing dumps on
the XML list:
http://lists.wikimedia.org/pipermail/xmldatadumps-l/2013-February/000701.html

Mariya



On Tue, Mar 5, 2013 at 4:15 PM, Quim Gil  wrote:

> On 03/05/2013 02:54 AM, Andreas Nüßlein wrote:
>
>> Hi list,
>>
>> so I need to set up a local instance of the dewiki- and enwiki-DB with all
>> revisions.. :-D
>>
>
> Just in case:
> http://meta.wikimedia.org/**wiki/Mirroring_Wikimedia_**project_XML_dumps
>
> Also, you might want to ask / discuss at
>
> https://lists.wikimedia.org/**mailman/listinfo/offline-l
>
> Good luck with this interesting project!
>
> --
> 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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Next bugday: Mar 07, 15:00-21:00UTC on General MediaWiki bugs

[Andre Klapper]

Hi everybody,

Please join us on the next Wikimedia Bugday:

Thursday, March 07th, 15:00-21:00 UTC [1]
   in #wikimedia-dev on Freenode IRC [2]

We are going to take a look at a subset [3] of MediaWiki bug reports
filed under "General/Unknown", trying to reproduce some plus provide
feedback. Currently these are about 90 tickets (see [4] for a list).

Everyone is welcome to join, and no technical knowledge needed! It's a
nice and easy way to get involved in the community or to give something
back. 
Join IRC, say hello and that you're here for the bugday, and have fun.

This information and more can be found here:
https://www.mediawiki.org/wiki/Bug_management/Triage/20130307

For more information on Triaging in general, check out
https://www.mediawiki.org/wiki/Bug_management/Triage

We look forward to seeing you!

andre


[1] Timezone converter: http://www.timeanddate.com/worldclock/converter.html
[2] See http://meta.wikimedia.org/wiki/IRC for more info on IRC chat
[3] with priority and severity set to normal or higher
[4] 
https://bugzilla.wikimedia.org/buglist.cgi?priority=Immediate&priority=Highest&priority=High&priority=Normal&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&resolution=---&query_format=advanced&component=General%2FUnknown&product=MediaWiki

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


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

Re: [Wikitech-l] QUnit testing in Jenkins

[Dan Andreescu]

> 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Seemingly proprietary Javascript

[Mark Holmquist]

On Tue, Mar 05, 2013 at 12:56:23PM +0100, Alexander Berntsen wrote:
> GNU LibreJS blocks several Javascript sources around Wikipedia. I was
> sent to this list by Kirk Billund. My issue as well as Kirk's replies
> follows. I hope you are okay to read it in this form.

https://bugzilla.wikimedia.org/show_bug.cgi?id=36866

We have this issue reported, it's on our radar, and I, at least, intend to fix 
it in the future.

The user JavaScript and CSS might be an issue. I'm not sure how to handle that. 
I guess we could indicate in the license headers that some parts of the code 
are under the CC-BY-SA license, or whatever is set to the default license for 
the wiki. That should be possible, if not trivial.

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. Alternatively we could use a "mixed" license 
header, and link to the texts of multiple licenses, or link to multiple files' 
source code.

See the linked bug (above) for more discussion of the technical problems 
presented, and a few proposed suggestions. It looks like the best way to do it 
would be the "bang comment" syntax, suggested by Timo (Krinkle), which would 
allow each script to be tagged on its own, and that way each script authour 
would be responsible for their own licensing.

I hope that helps, and that the bug discussion is a little more kind than 
wikitech has seemed :)

-- 
Mark Holmquist
Software Engineer
Wikimedia Foundation
mtrac...@member.fsf.org
https://wikimediafoundation.org/wiki/User:MHolmquist


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

Re: [Wikitech-l] Seemingly proprietary Javascript

[Luke Welling WMF]

I don't see the purpose of adding a licence string back on to JavaScript
post-minification.  Any recipient wanting to create a derivative work or
redistribute those files is going to go back to the much more readable
source files.

It would be good form to add licence information to all the JS files in the
same way we do for all the PHP files. Many or all of them are missing that
now.  Given they have a consistent licence, making that clear in each file
is just grunt work.

I don't see the need for that to survive minificaiton though. If somebody
wants to auto verify licence status with software, they can run it on the
original JS source before it get's minified. As others have implied
regardless of whether you think satisfying the FSF is important, satisfying
an automated tool is a concern that can be delegated to the tool owner.

The licence status of on wiki user JavaScript is a separate issue, and
possibly much more complicated.  CC-BY-SA-3.0 is not an ideal licence for
software, and it seems likely that there will be code pasted into some
user JavaScript pages that is licensed under an incompatible licence.

Luke Welling


On Tue, Mar 5, 2013 at 10:57 AM, Mark Holmquist wrote:

> On Tue, Mar 05, 2013 at 12:56:23PM +0100, Alexander Berntsen wrote:
> > GNU LibreJS blocks several Javascript sources around Wikipedia. I was
> > sent to this list by Kirk Billund. My issue as well as Kirk's replies
> > follows. I hope you are okay to read it in this form.
>
> https://bugzilla.wikimedia.org/show_bug.cgi?id=36866
>
> We have this issue reported, it's on our radar, and I, at least, intend to
> fix it in the future.
>
> The user JavaScript and CSS might be an issue. I'm not sure how to handle
> that. I guess we could indicate in the license headers that some parts of
> the code are under the CC-BY-SA license, or whatever is set to the default
> license for the wiki. That should be possible, if not trivial.
>
> 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. Alternatively we could use a
> "mixed" license header, and link to the texts of multiple licenses, or link
> to multiple files' source code.
>
> See the linked bug (above) for more discussion of the technical problems
> presented, and a few proposed suggestions. It looks like the best way to do
> it would be the "bang comment" syntax, suggested by Timo (Krinkle), which
> would allow each script to be tagged on its own, and that way each script
> authour would be responsible for their own licensing.
>
> I hope that helps, and that the bug discussion is a little more kind than
> wikitech has seemed :)
>
> --
> Mark Holmquist
> Software Engineer
> Wikimedia Foundation
> mtrac...@member.fsf.org
> https://wikimediafoundation.org/wiki/User:MHolmquist
>
>
> ___
> 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

[Antoine Musso]

Le 05/03/13 03:56, Alexander Berntsen a écrit :
>> Is it not possible to insert the licence as part of your build 
>> process? What I do with compiled or minified Javascript is to
>> build everything, and then insert the licence to all files using
>> BASH.

PLEASE NO. Let's not start a drama.

The JS are sent to the client in an optimized version. There is Zero
technical justification to add the long legal header.  The website
serving the files is already showing a link to mediawiki.org and our
license are pretty clear.

I can understand the legal reasons behind it, but lets stop being too
picky on that.

-- 
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

[Chad]

On Tue, Mar 5, 2013 at 8:23 AM, Luke Welling WMF  wrote:
> I don't see the purpose of adding a licence string back on to JavaScript
> post-minification.  Any recipient wanting to create a derivative work or
> redistribute those files is going to go back to the much more readable
> source files.
>
> It would be good form to add licence information to all the JS files in the
> same way we do for all the PHP files. Many or all of them are missing that
> now.  Given they have a consistent licence, making that clear in each file
> is just grunt work.
>
> I don't see the need for that to survive minificaiton though. If somebody
> wants to auto verify licence status with software, they can run it on the
> original JS source before it get's minified. As others have implied
> regardless of whether you think satisfying the FSF is important, satisfying
> an automated tool is a concern that can be delegated to the tool owner.
>

I think this makes the most sense. Files that don't have licenses
should have them, and they'd be shown in non-minified mode.

Serving license headers in minified mode is kind of silly (it defeats
part of the point)--and I think that "web labels" idea is equally silly.

-Chad

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

Re: [Wikitech-l] Extensions meta repo problem with MaintenanceShell

[Krinkle]

On Mar 3, 2013, at 7:04 AM, Chad  wrote:

> On Sat, Mar 2, 2013 at 9:56 PM, Jeremy Baron  wrote:
>> On Sun, Mar 3, 2013 at 5:50 AM, Brion Vibber  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

[Isarra Yos]

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 wrote:


On 4 March 2013 14:59, Krenair  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

[Krinkle]

On Mar 5, 2013, at 3:49 PM, Dan Andreescu  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

[Tyler Romeo]

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

[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

[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.

J.



On 5 March 2013 09:14, Isarra Yos  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 > >**wrote:
>>
>>  On 4 March 2013 14:59, Krenair  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
>



-- 
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

[Isarra Yos]

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 wrote:


On 4 March 2013 14:59, Krenair  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

[Bartosz Dziewoński]

On Mon, 04 Mar 2013 17:03:58 +0100, Tim Landscheidt  
wrote:


Bartosz Dziewoński  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

[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  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-l
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Seemingly proprietary Javascript

[Tyler Romeo]

On Tue, Mar 5, 2013 at 12:25 PM, Marc A. Pelletier  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

[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 wrote:

> On Mon, 04 Mar 2013 17:03:58 +0100, Tim Landscheidt <
> t...@tim-landscheidt.de> wrote:
>
>  Bartosz Dziewoński  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
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Github/Gerrit mirroring

[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

[Isarra Yos]

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  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!)

[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

[Caroline E Willis]

Is there a Counsel we can refer this to?
On Mar 5, 2013 11: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.
>
> On 05/03/13 17:36, Tyler Romeo wrote:
>
>> On Tue, Mar 5, 2013 at 12:25 PM, Marc A. Pelletier 
>> 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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Seemingly proprietary Javascript

[Krinkle]

On Mar 5, 2013, at 6:22 PM, Tyler Romeo  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 f

Re: [Wikitech-l] QUnit testing in Jenkins

[Erik Moeller]

On Mon, Mar 4, 2013 at 8:07 PM, Ori Livneh  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

[Luis Villa]

On Tue, Mar 5, 2013 at 10:10 AM, Caroline E Willis
wrote:

> 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"  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 
> >> 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

[Ryan Kaldari]

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

On Tue, Mar 5, 2013 at 8:56 AM, Alexander Berntsen  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

[Jay Ashworth]

- Original Message -
> From: "Mark Holmquist" 

> 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

[Krinkle]

On Mar 5, 2013, at 6:39 PM, Jon Robson  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

[Matthew Flaschen]

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

[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"  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

[Tyler Romeo]

On Tue, Mar 5, 2013 at 2:11 PM, Jay Ashworth  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

[James Forrester]

On 5 March 2013 11:55, Matthew Flaschen  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

[Jay Ashworth]

- Original Message -
> From: "Tyler Romeo" 

> > 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

[Tyler Romeo]

On Tue, Mar 5, 2013 at 3:08 PM, Jay Ashworth  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

[Nischay Nahata]

On Mon, Mar 4, 2013 at 7:06 AM, Quim Gil  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:
>
> http://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" + 
>
>
>  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/GitCommitMessages
>
> Chromium - Contributing code
> http://www.chromium.org/**developers/contributing-code
>
> Qt - Introduction to Gerrit
> http://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/
>
> EGit - Contributor Guide
> http://wiki.eclipse.org/EGit/**Contributor_Guide
>
> Gerrit Code Review - Contributing
> https://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/
>
>
> --
> 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
>



-- 
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

[Brian Wolff]

>
>
> 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

[Jay Ashworth]

- Original Message -
> From: "Tyler Romeo" 

> 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

[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 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).
>
> 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

[Brian Wolff]

On 2013-03-05 4:28 PM, "Jay Ashworth"  wrote:
>
> - Original Message -
> > From: "Tyler Romeo" 
>
> > 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

[Matthew Flaschen]

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

[Matthew Flaschen]

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

[Matthew Flaschen]

On 03/05/2013 12:27 PM, Jay Ashworth wrote:
> - Original Message -
>> From: "Tyler Romeo" 
> 
>> 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

[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

[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

[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

[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

[Tyler Romeo]

On Tue, Mar 5, 2013 at 5:01 PM, Ryan Kaldari  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

[David Gerard]

On 5 March 2013 22:08, Tyler Romeo  wrote:
> On Tue, Mar 5, 2013 at 5:01 PM, Ryan Kaldari  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

[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:
.

A number of former and current contributors (notably Lee Daniel Crocker)
have released their creative works and inventions into the public domain:
.

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

[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

[Greg Grossmeier]

> 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

[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

[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

[Brian Wolff]

On 2013-03-05 6:29 PM, "MZMcBride"  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:
> .
>
> A number of former and current contributors (notably Lee Daniel Crocker)
> have released their creative works and inventions into the public domain:
> .
>
> 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

[Petr Onderka]

On Tue, Mar 5, 2013 at 9:16 PM, Tyler Romeo  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

[Matthew Flaschen]

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

[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

[Matthew Flaschen]

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

[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:
> .

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

[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

[Brian Wolff]

On 2013-03-05 9:17 PM, "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:
> > .
>
> 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

[Matthew Flaschen]

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

[Matthew Flaschen]

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

[Brian Wolff]

On 2013-03-05 9:20 PM, "Sumana Harihareswara"  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...



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

[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"  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
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Seemingly proprietary Javascript

[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: .
>
>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 2+2=4 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

[Brian Wolff]

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"  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"  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

[Isarra Yos]

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

[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  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"  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"  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

[Krinkle]

On Mar 6, 2013, at 2:43 AM, Matthew Flaschen  wrote:

> 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
> 

Considering the "global" aspect it may be more useful (and flexible) to enforce 
this from the global script instead of from local preferences, which are rather 
annoying to maintain imho.

if ( dbname == wikidatawiki || .. ) {
 return;
}

-- Krinkle


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

Re: [Wikitech-l] Seemingly proprietary Javascript

[Chris Grant]

This is based on a flawed reading of the GPL. The GPL covers the
distribution of program code. The license specifically states that “The act
of running the Program is not restricted”. (Furthermore: “Activities other
than copying, distribution and modification are not covered by this
License; they are outside its scope.”)

The terms you are all referring to relate to the distribution of the
software, not the running of the software. Wikipedia.org, does not
distribute the software, that is MediaWiki.org's job. If Wikipedia wanted
to, we could remove all licensing information from the software and it
would still be completely legal. The GPL *only* comes into effect once you
start distributing the software.

This is why other licenses such as the Affero General Public License have
been written, to stop people using and modifying software like Mediawiki,
but failing to release their modifications back to the community.

The current method of distributing Mediawiki via Mediawiki.org is perfectly
complaint with the GPL.

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