[Wikitech-l] AJAX sharing of Commons data/metadata
As you know, wikisource needs robust, well-defined data, and there's a
strict, deep relationship between wikisource and Commons since Commons
hosts images of books, in .djvu or .pdf files. Commons shares both images
and contents fo information page of images, so that any wiki project can
visualize a view-only pseudo-page accessing to a local page named as the
file name into Commons.
Working into self-made data semantization into it.wikisouce using a lot of
creative tricks, we discovered that it's hard/almost impossible to read by
AJAX calls the contents of pages of other projects since well-known same
origin policy, but that File: local pages are considered as coming from
same origin so that they can be read as any other local page, and this
AJAX call asking for the content of
i.e. File:Die_Judenfrage_in_Deutchland_1936.djvu:
html=$.ajax({url:
http://wikisource.org/wiki/File:Die_Judenfrage_in_Deutchland_1936.djvu
,async:false}).responseText;
gives back the html text of local File: view-only page, and this means that
any data stored into information page into Commons is freely accessible by
a javascript script and can easily used locally. In particular, data stored
into information and/or (much better) Book and Creator templates can be
retrieved and parsed
Has this been described/used before? It seems a plain, simple way to share
and disseminate good, consistent metadata into any project; and this runs
from today, without any change on current wiki software.
If you like, I'm sharing a practical test use of this trick into
wikisource.org too, you can import User:Alex brollo/Library.js and a lot of
smallo, original scripts will be loaded; click on metadata botton from
any page connected to a File: page ( namespaces Index, Page) and you'll see
a result coming from such an AJAX call.
Alex brollo, from it.wikisource
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] $( 'div' ) vs. $( 'div /') in coding conventions (and methods for building DOMs with jQuery)
I will rescue two facts listed in this thread, about using jquery and
creating tags
[quote][1]
Basically $( 'span class=foo' ) will break completely in IE7/IE8.
[quote][2]
It's important to note however that IE required that input and button tags
are created with a type (if they are going to have a specific one)
$( 'input type=password', { 'class', 'example' } );
--
--
ℱin del ℳensaje.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Notification bubble system
It looks like NotifyOSD[1] and think it will work very well with echo[2]. I think an interesting thing would be the ability to position it on the screen through the preferences[3] [1]https://wiki.ubuntu.com/NotifyOSD [2]https://www.mediawiki.org/wiki/Echo_(Notifications) [3]https://www.mediawiki.org/wiki/Special:Preferences 2012/8/28 Helder . helder.w...@gmail.com On Tue, Aug 28, 2012 at 10:01 PM, Lars Aronsson l...@aronsson.se wrote: The auto-hide might be smooth for experienced computer users, but perhaps not for the elderly people that we try to recruit as new editors. That is one more use case for this: https://bugzilla.wikimedia.org/show_bug.cgi?id=30401 Helder ___ 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] [testing] TitleBlacklist now tested under Jenkins
Hello, After much hassle with Jenkins, ant and PHPUnit, I finally managed to run an extension PHPUnit test suite under Jenkins. The winner is TitleBlacklist for which results are available via: https://integration.mediawiki.org/ci/job/Ext-TitleBlacklist/ The Jenkins job is setup to report the build status back in Gerrit. If you see any issue, please fill in a bug under Testing infrastructure. TODO: Job does not run PHP lint yet. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [testing] TitleBlacklist now tested under Jenkins
Are there any plans to move more extensions (or at least those with unit tests) under Jenkins? Because I know one of my extension (TwoFactorAuthentication) has unit tests. *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Aug 29, 2012 at 10:18 AM, Antoine Musso hashar+...@free.fr wrote: Hello, After much hassle with Jenkins, ant and PHPUnit, I finally managed to run an extension PHPUnit test suite under Jenkins. The winner is TitleBlacklist for which results are available via: https://integration.mediawiki.org/ci/job/Ext-TitleBlacklist/ The Jenkins job is setup to report the build status back in Gerrit. If you see any issue, please fill in a bug under Testing infrastructure. TODO: Job does not run PHP lint yet. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [testing] TitleBlacklist now tested under Jenkins
On Wed, Aug 29, 2012 at 10:18 AM, Antoine Musso hashar+...@free.fr wrote: Hello, After much hassle with Jenkins, ant and PHPUnit, I finally managed to run an extension PHPUnit test suite under Jenkins. The winner is TitleBlacklist for which results are available via: https://integration.mediawiki.org/ci/job/Ext-TitleBlacklist/ The Jenkins job is setup to report the build status back in Gerrit. If you see any issue, please fill in a bug under Testing infrastructure. Question: why does the config for non-extension tests attempt to load extensions? -Parser and -Misc both seem to be failing due to a broken inclusion of Wikibase. Core tests should be run without any extensions. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [testing] TitleBlacklist now tested under Jenkins
Le 29/08/12 16:24, Tyler Romeo a écrit : Are there any plans to move more extensions (or at least those with unit tests) under Jenkins? Because I know one of my extension (TwoFactorAuthentication) has unit tests. Ultimately, all extensions hosted on WMF git server will be integrated in Jenkins. If you get PHPUnit test, I will add a job for it as soon as the current jobs are stable enough. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [testing] TitleBlacklist now tested under Jenkins
Ultimately, all extensions hosted on WMF git server will be integrated in Jenkins. If you get PHPUnit test, I will add a job for it as soon as the current jobs are stable enough. Awesome! *--* *Tyler Romeo* Stevens Institute of Technology, Class of 2015 Major in Computer Science www.whizkidztech.com | tylerro...@gmail.com On Wed, Aug 29, 2012 at 10:47 AM, Antoine Musso hashar+...@free.fr wrote: Le 29/08/12 16:24, Tyler Romeo a écrit : Are there any plans to move more extensions (or at least those with unit tests) under Jenkins? Because I know one of my extension (TwoFactorAuthentication) has unit tests. Ultimately, all extensions hosted on WMF git server will be integrated in Jenkins. If you get PHPUnit test, I will add a job for it as soon as the current jobs are stable enough. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [testing] TitleBlacklist now tested under Jenkins
On 29.08.2012, 18:27 Chad wrote: Question: why does the config for non-extension tests attempt to load extensions? -Parser and -Misc both seem to be failing due to a broken inclusion of Wikibase. Core tests should be run without any extensions. Ideally, core tests should include as many extension tests as possible to prevent core from silently breaking extensions. -- 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] [testing] TitleBlacklist now tested under Jenkins
On Wed, Aug 29, 2012 at 10:53 AM, Max Semenik maxsem.w...@gmail.com wrote: On 29.08.2012, 18:27 Chad wrote: Question: why does the config for non-extension tests attempt to load extensions? -Parser and -Misc both seem to be failing due to a broken inclusion of Wikibase. Core tests should be run without any extensions. Ideally, core tests should include as many extension tests as possible to prevent core from silently breaking extensions. That's why we write tests for extensions. You could very easily write two extensions that produce conflicting output--core should not break because of this. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [testing] TitleBlacklist now tested under Jenkins
Hey, Ultimately, all extensions hosted on WMF git server will be integrated in Jenkins. If you get PHPUnit test, I will add a job for it as soon as the current jobs are stable enough. Thanks for your work on this! :) Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [testing] TitleBlacklist now tested under Jenkins
On Wed, Aug 29, 2012 at 11:01 AM, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, Ultimately, all extensions hosted on WMF git server will be integrated in Jenkins. If you get PHPUnit test, I will add a job for it as soon as the current jobs are stable enough. Thanks for your work on this! :) Indeed! I should've said so in my first e-mail. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [testing] TitleBlacklist now tested under Jenkins
Core tests should be run without any extensions. Ideally, core tests should include as many extension tests as possible to prevent core from silently breaking extensions. That's why we write tests for extensions. You could very easily write two extensions that produce conflicting output--core should not break because of this. I think we have three different things going on here. * Unit tests for extensions to prevent core changes from breaking extensions * Unit tests for core (with extensions enabled) to prevent core changes from breaking extensions. * Unit tests for core (with extensions enabled) to prevent conflicting extensions from breaking the core. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [testing] TitleBlacklist now tested under Jenkins
Ultimately, all extensions hosted on WMF git server will be integrated in Jenkins. If you get PHPUnit test, I will add a job for it as soon as the current jobs are stable enough. At the risk of sounding unoriginal, _zomg this is amazing_. Thanks a bunch, Antoine! -- Mark Holmquist Contractor, Wikimedia Foundation mtrac...@member.fsf.org http://marktraceur.info ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] AJAX sharing of Commons data/metadata
On Wed, Aug 29, 2012 at 12:39 AM, Alex Brollo alex.bro...@gmail.com wrote:
As you know, wikisource needs robust, well-defined data, and there's a
strict, deep relationship between wikisource and Commons since Commons
hosts images of books, in .djvu or .pdf files. Commons shares both images
and contents fo information page of images, so that any wiki project can
visualize a view-only pseudo-page accessing to a local page named as the
file name into Commons.
Working into self-made data semantization into it.wikisouce using a lot of
creative tricks, we discovered that it's hard/almost impossible to read by
AJAX calls the contents of pages of other projects since well-known same
origin policy, but that File: local pages are considered as coming from
same origin so that they can be read as any other local page, and this
AJAX call asking for the content of
i.e. File:Die_Judenfrage_in_Deutchland_1936.djvu:
html=$.ajax({url:
http://wikisource.org/wiki/File:Die_Judenfrage_in_Deutchland_1936.djvu
,async:false}).responseText;
gives back the html text of local File: view-only page, and this means that
any data stored into information page into Commons is freely accessible by
a javascript script and can easily used locally. In particular, data stored
into information and/or (much better) Book and Creator templates can be
retrieved and parsed
Has this been described/used before? It seems a plain, simple way to share
and disseminate good, consistent metadata into any project; and this runs
from today, without any change on current wiki software.
[..]
You can also do this more directly using JSON with callback - Define a
function foo, and put
http://commons.wikimedia.org/w/api.php?action=parsepage=Main_Pageformat=jsoncallback=foo
as the src of the script tag. This works for certain safe api
methods. In future we may support CORS which will allow full
cross-origin js requests between Wikimedia sites
However, I think the main issue is that people want to do more things
with metadata than just retrieving the information with js. I suppose
it all boils down to use-cases. I'll admit I'm not overly familiar
with Wikisource's metadata use case.
--
-bawolff
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] AJAX sharing of Commons data/metadata
On Thu, Aug 30, 2012 at 12:25 AM, bawolff bawolff...@gmail.com wrote: You can also do this more directly using JSON with callback - Define a function foo, and put http://commons.wikimedia.org/w/api.php?action=parsepage=Main_Pageformat=jsoncallback=foo as the src of the script tag. This works for certain safe api methods. In future we may support CORS which will allow full cross-origin js requests between Wikimedia sites Has there been any discussion of CORS support in Mediawiki / WMF sites anywhere? -- Yuvi Panda T http://yuvi.in/blog ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] AJAX sharing of Commons data/metadata
Has there been any discussion of CORS support in Mediawiki / WMF sites anywhere? There was some talk of it in bug 32890 [0] in UploadWizard, and I tried to throw together code for it in a patchset [1], but I didn't spend much time on it (the effort was mostly to put the code into a workable patchset rather than just a snippet in a bug). bawolff also commented on the patchset and linked to bug 20814 [2], which is further discussion of the topic in broader strokes. [0] https://bugzilla.wikimedia.org/show_bug.cgi?id=32890 [1] https://gerrit.wikimedia.org/r/#/c/9718/ [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=20814 -- Mark Holmquist Contractor, Wikimedia Foundation mtrac...@member.fsf.org http://marktraceur.info ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] AJAX sharing of Commons data/metadata
As mentioned in those bugs, mediawiki support a basic CORS implementation already. It looks like we haven't authorized any domain for wmf projects though. On Wed, Aug 29, 2012 at 12:03 PM, Mark Holmquist mtrac...@member.fsf.org wrote: Has there been any discussion of CORS support in Mediawiki / WMF sites anywhere? There was some talk of it in bug 32890 [0] in UploadWizard, and I tried to throw together code for it in a patchset [1], but I didn't spend much time on it (the effort was mostly to put the code into a workable patchset rather than just a snippet in a bug). bawolff also commented on the patchset and linked to bug 20814 [2], which is further discussion of the topic in broader strokes. [0] https://bugzilla.wikimedia.org/show_bug.cgi?id=32890 [1] https://gerrit.wikimedia.org/r/#/c/9718/ [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=20814 -- Mark Holmquist Contractor, Wikimedia Foundation mtrac...@member.fsf.org http://marktraceur.info ___ 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] Disabling direct pushing to master for extensions
Hi everyone, This is something I've been meaning to bring up for some time, but have just been delaying getting it done. For a bunch of reasons, we need to look at disabling direct pushing on the master branch for all extensions in Gerrit. This doesn't affect other branches, just master. There's a couple of big reasons this is a problem right now, and why we need to change: 1) Eventually, we'll be running tests for all extensions (at the very least linting if no phpunit tests have been written). Jenkins doesn't have the change to -1 a commit if you skip review. 2) It doesn't give anyone a place to complain about the patch. Every commit to master needs a place to say Hey wait a minute -- even if it's already been merged. 3) Changes that are directly pushed aren't searchable from Gerrit. This is more a feature request for Gerrit, but one that's easily worked around by just pushing through Gerrit. I realize that feature branches don't necessarily need the same level of scrutiny, but the primary branch for a repository needs to be as public as possible--direct pushing makes this difficult. I don't plan on changing this requirement for any branch that's not master or wmf/ (the latter relating to deployment config). Before I make the change though, I wanted to ask about it publicly to make sure there's no major blockers to me doing so. Thanks for any feedback you can give. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] AJAX sharing of Commons data/metadata
On Wed, Aug 29, 2012 at 2:55 PM, Chris Steipp cste...@wikimedia.org wrote: As mentioned in those bugs, mediawiki support a basic CORS implementation already. It looks like we haven't authorized any domain for wmf projects though. Looks like Roan is taking charge on it on bug 20814, yay. :) There are also open requests about setting up CORS headers to allow read access to upload bits: https://bugzilla.wikimedia.org/show_bug.cgi?id=28700 https://bugzilla.wikimedia.org/show_bug.cgi?id=25886 Access for upload is important for supporting web-based tools for SVG or raster image editing (eg deploying SVGEditor extension). [Note that we want *other sites* to be able to load files from upload.wikimedia.org, not files on upload.wikimedia.org to be able to open anything else. :)] -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disabling direct pushing to master for extensions
Am 29.08.2012 21:58, schrieb Chad: Hi everyone, This is something I've been meaning to bring up for some time, but have just been delaying getting it done. For a bunch of reasons, we need to look at disabling direct pushing on the master branch for all extensions in Gerrit s much information. Life was much easier before the big switch-over from svn to git, and gerrit in spring 2012. signature.asc Description: OpenPGP digital signature ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disabling direct pushing to master for extensions
Chad, how will this affect my workflow? I suspect it'll complicate it further and make me do some other funky things before I can submit a change. Right now this is how I work with my extensions: (0. clone the git repo) 1. edit the code 2. commit the changes 3. push the committed changeset/patchset/whatever you want to call it If it matters, I'm on Windows (7 for the time being) using TortoiseGit. On Wed, Aug 29, 2012 at 11:06 PM, Thomas Gries m...@tgries.de wrote: s much information. Life was much easier before the big switch-over from svn to git, and gerrit in spring 2012. I do miss the time when things Just Worked™ and I could focus on coding instead of messing around with the VCS. (And if this sounds personal to any of you, it's not; I just very much dislike git, gerrit and whatever our current workflow for core MW + WMF-deployed extensions is. I hardly have any motivation for committing code to core MW and for that, the setup is to be thanked.) Thanks and regards, -- Jack Phoenix MediaWiki developer ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disabling direct pushing to master for extensions
On Wed, Aug 29, 2012 at 12:58 PM, Chad innocentkil...@gmail.com wrote: Before I make the change though, I wanted to ask about it publicly to make sure there's no major blockers to me doing so. As long as people that were previously able to push are still able to +2 (which is probably true, unless the ACLs are really weird), and as long as self-review isn't prevented by the software in the future (there was some discussion about this at some point), I think this'll be fine, because extension maintainers that used to use direct push can submit their change for review, then approve it themselves. I maintain that self-review is evil for core and deployed extensions, but for undeployed extensions that don't have multiple active maintainers I think it's fine. Also, didn't Shawn say there were vague plans to make direct pushes actually create changes and stuff? If and when that happens, I'd like to open direct push back up, because really this self-review workflow is a workaround for the fact that Gerrit doesn't handle direct pushes very well. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] AJAX sharing of Commons data/metadata
Thanks for comments. Relationship between wikisource and Commons is very strict, and there's a large 1:1 match between structured wikisource data stored into well-formed templates (used into nsIndex and ns0) and Book template; there's too a 1:1 relationship between nsCreator into Commons and nsAuthor into wikisource. Djvu and (less used) pdf files are already shared among different wikisource projects, but data stored into information page of files are not shared, so that any project rewrites them and stores them with a variety of formats and contents, introducing redundance and mining deeply coherence. So, we are going to use Commons metadata - already stored into Book and Creator templates - to share them widely anong all projects that need them. When metadata are uploaded and parsed they can be used to feed local wikisource templates and/or to align data with automated procedures. Thanks for API suggestion, but the question is: does it violates same origin AJAX policy? I can read anything by a bot from any project, but AJAX is great to enhance interactivity and to help user just when user needs data, i.e. in edit mode. Yes, the solution will be CORS, but I can't wait for future enhancements when data can be accessed and used today, with present software. Alex brollo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] AJAX sharing of Commons data/metadata
On Wed, Aug 29, 2012 at 2:24 PM, Alex Brollo alex.bro...@gmail.com wrote: Thanks for comments. [..] Thanks for API suggestion, but the question is: does it violates same origin AJAX policy? I can read anything by a bot from any project, but AJAX is great to enhance interactivity and to help user just when user needs data, i.e. in edit mode. No it doesn't violate the same origin policy. Same origin policy only prevents reading information from other websites, it does not stop you from executing content from other websites (Which always seemed an odd distinction to me...). Thus you can use the api with a callback parameter to get around the same origin policy. Obviously CORS is a much nicer solution. -bawolff ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disabling direct pushing to master for extensions
Hey, I see several workflow issues I will have if this was applied to all extensions: * Creating tags and pushing them - can this be done using gitreview? * Someone makes a pile of commits on some alternate remote or just locally and then wants to push them to the wmf hosted repo. If the stuff has already been reviewed, having to manually self-approve all of them is just ridiculous. * What if you merge a branch of which the commits have already been reviewed into master and then want to push that? Same problem as above? In any case, I'm mostly using gitreview for my changes so they show up in gerrit, but every so often I run into a usecase where it really makes no sense to use it. I don't see what I would gain by preventing me from doing that for my own extensions, so think extensions owners definitely should keep the right for their own extensions. At least for non-WMF extensions that is. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Appreciation thread
Even further thanks to Siebrand and Niklas for their stellar help in fixing a huge l10n regression today. The l10n folks do so much work to support so many people, and they're amazing at it. Bravo. -- Mark Holmquist Contractor, Wikimedia Foundation mtrac...@member.fsf.org http://marktraceur.info ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disabling direct pushing to master for extensions
On Wed, Aug 29, 2012 at 4:44 PM, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, I see several workflow issues I will have if this was applied to all extensions: * Creating tags and pushing them - can this be done using gitreview? This is still doable via normal git commands. Nothing there changes. * Someone makes a pile of commits on some alternate remote or just locally and then wants to push them to the wmf hosted repo. If the stuff has already been reviewed, having to manually self-approve all of them is just ridiculous. * What if you merge a branch of which the commits have already been reviewed into master and then want to push that? Same problem as above? Only if they're pushing to master. It would make sense to have done the work on the branch, merge it to master, and then just push the merge commit for review. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disabling direct pushing to master for extensions
Hey, Only if they're pushing to master. It would make sense to have done the work on the branch, merge it to master, and then just push the merge commit for review. Forgive my git ignorance here, but will merging this merge commit result into all original commits being in the version history, or will it just show as one huge change? In case of the later, I don't think this is an acceptable approach. Cheers -- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. -- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] 5 tips to get your code reviewed faster
Version with helpful links: https://www.mediawiki.org/wiki/Git/Code_review/Getting_reviews 1) Write small commits. It's easier for other people to review small changes that only change one thing. We'd rather see five small commits than one big one. 2) Respond to test failures and feedback. Check your Gerrit settings and make sure you're getting email notifications. If your code fails automated tests, or you got some review already, respond to it in a comment or resubmission. Or hit the Abandon button to remove your commit from the review queue while you revise it. (To see why automated tests fail, click on the link in the failed comment in Gerrit, hover over the failed test's red dot, wait for the popup to show, and then click console output.) 3) Don't mix rebases with changes. When rebasing, only rebase. That makes it easier to use the Old Version History dropdown, which greatly quickens reviews. If non-rebase changes are made inside a rebase changeset, you have to read through a lot more code to find it and it's non-obvious. 4) Add reviewers. I try to help with this. If I notice an unreviewed changeset lingering, then I add a review request or two. (These are requests -- there's no way to assign a review to someone in Gerrit.) But it's faster if you do it right after committing. Some tricks: *Click the name of the repository (Gerrit project), e.g. operations/debs/squid , and remove status:open from the search box to find other changesets in that repository. The people who write and review those changesets would be good candidates to add as reviewers. *Search through other commit summaries and changesets. Example: Matmarex and Foxtrott are interested in reviewing frontend changes, so I search for message:css to find changesets that mention CSS in their commit summaries to add them to. You can use this and regexes to find changes that touch the same components you're touching, to find likely reviewers. Learn more at https://gerrit.wikimedia.org/r/Documentation/user-search.html . 5) Review more. Many eyes make bugs shallow. Read the code review guide and help out with comments, +1, and -1. Those are nonbinding, won't cause merges or rejections, and have no formal effect on the code review. But you'll learn, gain reputation, and get people to return the favor by reviewing you in the future. How to review code in Gerrit has the step-by-step explanation. Example Gerrit search for MediaWiki commits that have not had +1, +2, -1, or -2 reviews yet: https://gerrit.wikimedia.org/r/#/q/-CodeReview%252B1+-CodeReview%252B2+-CodeReview-1+-CodeReview-2+project:%255Emediawiki.*,n,z -- 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] 5 tips to get your code reviewed faster
Am 29.08.2012 23:55, schrieb Sumana Harihareswara: Version with helpful links: https://www.mediawiki.org/wiki/Git/Code_review/Getting_reviews 1) Write small commits. It's easier for other people to review small changes that only change one thing. We'd rather see five small commits than one big one. 2) Respond to test failures and feedback. Check your Gerrit settings and make sure you're getting email notifications. If your code fails automated tests, or you got some review already, respond to it in a comment or resubmission. Or hit the Abandon button to remove your commit from the review queue while you revise it. (To see why automated tests fail, click on the link in the failed comment in Gerrit, hover over the failed test's red dot, wait for the popup to show, and then click console output.) 3) Don't mix rebases with changes. When rebasing, only rebase. That makes it easier to use the Old Version History dropdown, which greatly quickens reviews. If non-rebase changes are made inside a rebase changeset, you have to read through a lot more code to find it and it's non-obvious. 4) Add reviewers. I try to help with this. If I notice an unreviewed changeset lingering, then I add a review request or two. (These are requests -- there's no way to assign a review to someone in Gerrit.) But it's faster if you do it right after committing. Some tricks: *Click the name of the repository (Gerrit project), e.g. operations/debs/squid , and remove status:open from the search box to find other changesets in that repository. The people who write and review those changesets would be good candidates to add as reviewers. *Search through other commit summaries and changesets. Example: Matmarex and Foxtrott are interested in reviewing frontend changes, so I search for message:css to find changesets that mention CSS in their commit summaries to add them to. You can use this and regexes to find changes that touch the same components you're touching, to find likely reviewers. Learn more at https://gerrit.wikimedia.org/r/Documentation/user-search.html . 5) Review more. Many eyes make bugs shallow. Read the code review guide and help out with comments, +1, and -1. Those are nonbinding, won't cause merges or rejections, and have no formal effect on the code review. But you'll learn, gain reputation, and get people to return the favor by reviewing you in the future. How to review code in Gerrit has the step-by-step explanation. Example Gerrit search for MediaWiki commits that have not had +1, +2, -1, or -2 reviews yet: https://gerrit.wikimedia.org/r/#/q/-CodeReview%252B1+-CodeReview%252B2+-CodeReview-1+-CodeReview-2+project:%255Emediawiki.*,n,z Something which needs so much text, is broken is some respect. Mies van der Rohe: Less is more. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disabling direct pushing to master for extensions
On Wed, Aug 29, 2012 at 1:55 PM, Jeroen De Dauw jeroended...@gmail.com wrote: Forgive my git ignorance here, but will merging this merge commit result into all original commits being in the version history, or will it just show as one huge change? In case of the later, I don't think this is an acceptable approach. It will still show up in the history as individual commits on the right-hand side of the merge commit, same as when you do 'git checkout master; git merge mybranch; git push'. Roan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] AJAX sharing of Commons data/metadata
2012/8/29 bawolff bawolff...@gmail.com On Wed, Aug 29, 2012 at 2:24 PM, Alex Brollo alex.bro...@gmail.com wrote: Thanks for comments. [..] Thanks for API suggestion, but the question is: does it violates same origin AJAX policy? I can read anything by a bot from any project, but AJAX is great to enhance interactivity and to help user just when user needs data, i.e. in edit mode. No it doesn't violate the same origin policy. Same origin policy only prevents reading information from other websites, it does not stop you from executing content from other websites (Which always seemed an odd distinction to me...). Thus you can use the api with a callback parameter to get around the same origin policy. Obviously CORS is a much nicer solution. -bawolff ___ 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] AJAX sharing of Commons data/metadata
No it doesn't violate the same origin policy. Same origin policy only prevents reading information from other websites, it does not stop you from executing content from other websites (Which always seemed an odd distinction to me...). Thus you can use the api with a callback parameter to get around the same origin policy. Ouch this is a little bit above my skill understanding (really I discovered AJAX not far ago). . Where can I find some examples of API inter-project data exchage wth callback parameter? I.e: I'd like to get the raw content and the html rendering of File:I_promessi_sposi_(1840).djvu from wikisource, with an AJAX callback call. Which is the needed code? :-( Alex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disabling direct pushing to master for extensions
On 29/08/12 22:44, Jeroen De Dauw wrote: I don't see what I would gain by preventing me from doing that for my own extensions, so think extensions owners definitely should keep the right for their own extensions. At least for non-WMF extensions that is. It's a workaround for gerrit being dumb and not processing the pushed changesets. Would git push of already-sent changesets still accept them, or should I look for the ssh commands for accepting? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] AJAX sharing of Commons data/metadata
On Wed, Aug 29, 2012 at 6:03 PM, Alex Brollo alex.bro...@gmail.com wrote:
Ouch this is a little bit above my skill understanding (really I
discovered AJAX not far ago). . Where can I find some examples of API
inter-project data exchage wth callback parameter?
I.e: I'd like to get the raw content and the html rendering
of File:I_promessi_sposi_(1840).djvu from wikisource, with an AJAX callback
call. Which is the needed code?
Luckily, if you're using jQuery much of the low-level stuff can be taken
care of for you. Something like this should work for API calls,
automatically using the callback behind the scenes:
$.ajax({
url: 'https://commons.wikimedia.org/w/api.php',
data: {
format: 'json',
// ... various settings ...
},
dataType: 'jsonp' // this is the important one!
}).done(function(data) {
// do some work here
alert(JSON.stringify(data));
});
You can look up the various parameters for different queries in the online
help at https://commons.wikimedia.org/w/api.php and/or playing with the API
sandbox at https://commons.wikimedia.org/wiki/Special:ApiSandbox
-- brion
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disabling direct pushing to master for extensions
On Wed, Aug 29, 2012 at 7:55 PM, Platonides platoni...@gmail.com wrote: On 29/08/12 22:44, Jeroen De Dauw wrote: I don't see what I would gain by preventing me from doing that for my own extensions, so think extensions owners definitely should keep the right for their own extensions. At least for non-WMF extensions that is. It's a workaround for gerrit being dumb and not processing the pushed changesets. Would git push of already-sent changesets still accept them, or should I look for the ssh commands for accepting? I think that depends where it was already sent too. If already in master then you should be able to push with no problem. If just to some other branch then a push to master would probably make a new changeset. -Jeremy ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disabling direct pushing to master for extensions
On Wednesday, August 29, 2012 at 12:58 PM, Chad wrote: For a bunch of reasons, we need to look at disabling direct pushing on the master branch for all extensions in Gerrit […] Before I make the change though, I wanted to ask about it publicly to make sure there's no major blockers to me doing so. E3 is using Phabricator for code-reviews, so this would complicate things for us. We could, I guess, have a separate Gerrit / +2 step. I'm curious, though: why is the scope for this proposal limited to extensions? Are other types of projects exempt? -- Ori ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Disabling direct pushing to master for extensions
For a bunch of reasons, we need to look at disabling direct pushing on the master branch for all extensions in Gerrit […] Before I make the change though, I wanted to ask about it publicly to make sure there's no major blockers to me doing so. E3 is using Phabricator for code-reviews, so this would complicate things for us. We could, I guess, have a separate Gerrit / +2 step. I'm curious, though: why is the scope for this proposal limited to extensions? Are other types of projects exempt? I think most projects already have it disabled. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
