Re: [Wikitech-l] Tools repository
> > -- > > Message: 6 > Date: Tue, 13 Oct 2015 19:41:08 -0400 > From: Pine W > To: Wikimedia developers > Subject: Re: [Wikitech-l] Tools repository > Message-ID: > dyjjbjex05lgmb7hx61we3y-kvjfkg1zoggeba1_h3b2...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > I like the idea of a tools index. Bob Cummings was looking for some GLAM > tools that IIRC sounded perfectly reasonable but no one seems to know if we > have them. > > Pine > Other than the ones listed at https://outreach.wikimedia.org/wiki/GLAM/Resources/Tools ? E. > On Oct 13, 2015 6:52 PM, "Quim Gil" wrote: > > > On Mon, Oct 12, 2015 at 7:04 PM, Ricordisamoa < > > ricordisa...@openmailbox.org> > > wrote: > > > > > Il 12/10/2015 18:56, Quim Gil ha scritto: > > > > > >> > > >> Interesting. Has there been any discussion about having an > authoritative > > >> and well promoted catalog of Wikimedia tools? > > >> > > > > > > Yes. > > > > https://lists.wikimedia.org/pipermail/labs-l/2015-March/thread.html#3462 > > > > > > After reading the (short) discussion, I think it is worth creating a task > > to assure that at least this idea is not forgotten again in another > mailing > > list archive. Ricordisamoa, do you want to create it and associate it at > > lest with the #Developer-Relations project? > > > > I also believe that we need a catalog of tools. Even when some experts in > > our community know or can find what is available and functional, most > > potential users of those tools will have a hard time connecting with > them. > > > > -- > > Quim Gil > > Engineering Community Manager @ 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] Need a way to modify text before indexing (was SearchUpdate)
I've written about my problem ~2 years ago: http://wikitech-l.wikimedia.narkive.com/6G0YPmWQ/need-a-way-to-modify-text-before-indexing-was-searchupdate It seems I've lost the latest message, so I want to answer to it now: With lsearchd and Elasticsearch, we absolutely wouldn't want to munge file text into page content (with sql-backed search, you might maybe). Why?? Aren't these also just the fulltext search backends? As I understand they're much faster than sql-backed search engines. What would prevent them to store file texts? Personally I use Sphinx (http://sphinxsearch.com) with TikaMW, and of course everything is fine. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Need a way to modify text before indexing (was SearchUpdate)
FWIW, we do index the full text of (PDF and?) DjVu files on Commons (because it's stored in img_metadata). It's probably the biggest improvement CirrusSearch brought for Commons. Nemo ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Need a way to modify text before indexing (was SearchUpdate)
FWIW, we do index the full text of (PDF and?) DjVu files on Commons (because it's stored in img_metadata). It's probably the biggest improvement CirrusSearch brought for Commons. And we also index office documents via Tika (*.doc and similar). And I think it should not be a feature of the search engine at all! It's a separate feature that's completely independent of the search engine used (that's how it's implemented in my TikaMW). So, is there any replacement for the SearchUpdate hook to modify the indexed text? Of course I can just return SearchUpdate back by including a patch in our distribution mediawiki4intranet, but I would prefer if TikaMW didn't require patching... ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] i would like that i need not set standart spacing in my code
i think i lose my individuality and that i have to make extra key presses to set extra spaces near brackets and commas. currently tests / automatical reviews show in gerrit that my commit has such errors. what if they are not (would not be? were not? ) blamed on commit (patch set) uploads, but only automatically prettified/standartised at/before actual commit/merge? and, by the way, i think, should not they even be saved as they are written and should not, instead, diff tools automatically standartise them before calculating difference? ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] is this list's archives searchable?
i do not see search form in https://lists.wikimedia.org/mailman/listinfo/wikitech-l and google has nothing for site:https://lists.wikimedia.org/pipermail/wikitech-l/ , because of robots.txt. see https://lists.wikimedia.org/robots.txt : # robots.txt for lists.wikimedia.org # # Disabled crawling for several lists 2005-11-26 to # discourage people from complaining about items they # post on public mailing lists being the first Google # search result about them. # # Note that list archives remain public. # User-agent: * Disallow: /pipermail/ i have just now posted about code formatting in gerrit, probably that was already discussed. but i could not search it in here. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] is this list's archives searchable?
i have seen a new message in this list and i have remembered about mailing list archives 2015-10-14 19:10 GMT+03:00 dinar qurbanov : > i do not see search form in > https://lists.wikimedia.org/mailman/listinfo/wikitech-l and google has > nothing for site:https://lists.wikimedia.org/pipermail/wikitech-l/ , > because of robots.txt. see https://lists.wikimedia.org/robots.txt : > > # robots.txt for lists.wikimedia.org > # > # Disabled crawling for several lists 2005-11-26 to > # discourage people from complaining about items they > # post on public mailing lists being the first Google > # search result about them. > # > # Note that list archives remain public. > # > > User-agent: * > Disallow: /pipermail/ > > i have just now posted about code formatting in gerrit, probably that > was already discussed. but i could not search it in here. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] i would like that i need not set standart spacing in my code
dinar qurbanov wrote: > i think i lose my individuality and that i have to make extra key > presses to set extra spaces near brackets and commas. currently tests > / automatical reviews show in gerrit that my commit has such errors. > what if they are not (would not be? were not? ) blamed on commit > (patch set) uploads, but only automatically prettified/standartised > at/before actual commit/merge? > and, by the way, i think, should not they even be saved as they are > written and should not, instead, diff tools automatically standartise > them before calculating difference? How would it help the reviewer if they constantly need to switch their mind from "prettified" code to "whatever" when they review your code? If you don't want to press the space bar, you can always in- tegrate stylize (http://git.wikimedia.org/blob/mediawiki%2Ftools%2Fcode-utils.git/master/stylize.php) in your workflow or amend your editor to insert the spaces when you type. Tim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] i would like that i need not set standart spacing in my code
FYI if you are talking about JavaScript you might want to explore http://jsbeautifier.org/ All code standards are currently being enforced by jscs. They recently closed an issue to add auto-formatting https://github.com/jscs-dev/node-jscs/issues/516 In theory, you could create a script to autoformat your code and write it in any style that appears comfortable to you. It would be useful for someone to explore this and comment back on results. We should be wasting less time on the appearance of code - making sure it adheres to standards - and instead focusing on the contents of its code. On Wed, Oct 14, 2015 at 9:39 AM, Tim Landscheidt wrote: > dinar qurbanov wrote: > > > i think i lose my individuality and that i have to make extra key > > presses to set extra spaces near brackets and commas. currently tests > > / automatical reviews show in gerrit that my commit has such errors. > > what if they are not (would not be? were not? ) blamed on commit > > (patch set) uploads, but only automatically prettified/standartised > > at/before actual commit/merge? > > > and, by the way, i think, should not they even be saved as they are > > written and should not, instead, diff tools automatically standartise > > them before calculating difference? > > How would it help the reviewer if they constantly need to > switch their mind from "prettified" code to "whatever" when > they review your code? > > If you don't want to press the space bar, you can always in- > tegrate stylize > ( > http://git.wikimedia.org/blob/mediawiki%2Ftools%2Fcode-utils.git/master/stylize.php > ) > in your workflow or amend your editor to insert the spaces > when you type. > > Tim > > > ___ > Wikitech-l mailing list > Wikitech-l@lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Jon Robson * http://jonrobson.me.uk * https://www.facebook.com/jonrobson * @rakugojon ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Google Mail marking Phabricator and Gerrit notification emails as spam
Just FYI for those on Google-hosted email. See: https://phabricator.wikimedia.org/T115416 TL;DR: Check your spam folder :) Greg -- | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] i would like that i need not set standart spacing in my code
> How would it help the reviewer if they constantly need to > switch their mind from "prettified" code to "whatever" when > they review your code? it is possible to show prettified code in gerrit web pages, and send prettified version to people if they get it via git fetch, but save also their original form . and, as another alternative, it is possible to save original form in author's computer, and automatically prettify it in gerrit server just after he pushes it into gerrit... > If you don't want to press the space bar, you can always in- > tegrate stylize > ( > http://git.wikimedia.org/blob/mediawiki%2Ftools%2Fcode-utils.git/master/stylize.php > ) > in your workflow or amend your editor to insert the spaces > when you type. then i would need to see that prettified code at my further local editions and sometimes i would have to manually delete that extra spaces during editing my code. 2015-10-14 20:23 GMT+03:00 Jon Robson : > FYI if you are talking about JavaScript you might want to explore > http://jsbeautifier.org/ > > All code standards are currently being enforced by jscs. > They recently closed an issue to add auto-formatting > https://github.com/jscs-dev/node-jscs/issues/516 > In theory, you could create a script to autoformat your code and write it > in any style that appears comfortable to you. It would be useful for > someone to explore this and comment back on results. > > We should be wasting less time on the appearance of code - making sure it > adheres to standards - and instead focusing on the contents of its code. > > > > On Wed, Oct 14, 2015 at 9:39 AM, Tim Landscheidt > wrote: > >> dinar qurbanov wrote: >> >> > i think i lose my individuality and that i have to make extra key >> > presses to set extra spaces near brackets and commas. currently tests >> > / automatical reviews show in gerrit that my commit has such errors. >> > what if they are not (would not be? were not? ) blamed on commit >> > (patch set) uploads, but only automatically prettified/standartised >> > at/before actual commit/merge? >> >> > and, by the way, i think, should not they even be saved as they are >> > written and should not, instead, diff tools automatically standartise >> > them before calculating difference? >> >> How would it help the reviewer if they constantly need to >> switch their mind from "prettified" code to "whatever" when >> they review your code? >> >> If you don't want to press the space bar, you can always in- >> tegrate stylize >> ( >> http://git.wikimedia.org/blob/mediawiki%2Ftools%2Fcode-utils.git/master/stylize.php >> ) >> in your workflow or amend your editor to insert the spaces >> when you type. >> >> Tim >> >> >> ___ >> Wikitech-l mailing list >> Wikitech-l@lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> > > > > -- > Jon Robson > * http://jonrobson.me.uk > * https://www.facebook.com/jonrobson > * @rakugojon > ___ > 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] i would like that i need not set standart spacing in my code
Apologies for the bluntness, but if you cannot conform to the coding standards of a project in terms of minor things such as spacing, how can we know or trust you that you are confirming to standards that are more meaningful, such as those related to security? Standards allow for a consistent appearance of the codebase both on an aesthetic and functional level. On the aesthetic side of things, we strive for code that is easy for humans to read and understand in order to assist in code reviews. Having a single defined standard to achieve that also adds a level of consistency and professionalism to the codebase. While I personally believe MediaWiki's style is too spacey, I understand the value in having all code conform to the standard and as a result I conform to it when coding for MediaWiki. I encourage you to look for and understand the value of a single standardized style as well as opposed to each developer coding however it suits them. On the technical side of things, consider merging in changes to someone else's work -- if your style clashes with theirs the result will look horrible and as a result be harder to read and understand. And if someone else comes back and makes an edit in somewhere slightly nearby, you'll have to deal with annoying merge conflicts due to whitespace issues instead of git just intelligently merging it all together automatically. On Oct 14, 2015, at 10:42 AM, dinar qurbanov wrote: >> How would it help the reviewer if they constantly need to >> switch their mind from "prettified" code to "whatever" when >> they review your code? > > it is possible to show prettified code in gerrit web pages, and send > prettified version to people if they get it via git fetch, but save > also their original form . > > and, as another alternative, it is possible to save original form in > author's computer, and automatically prettify it in gerrit server just > after he pushes it into gerrit... > >> If you don't want to press the space bar, you can always in- >> tegrate stylize >> ( >> http://git.wikimedia.org/blob/mediawiki%2Ftools%2Fcode-utils.git/master/stylize.php >> ) >> in your workflow or amend your editor to insert the spaces >> when you type. > > then i would need to see that prettified code at my further local > editions and sometimes i would have to manually delete that extra > spaces during editing my code. > > > > > 2015-10-14 20:23 GMT+03:00 Jon Robson : >> FYI if you are talking about JavaScript you might want to explore >> http://jsbeautifier.org/ >> >> All code standards are currently being enforced by jscs. >> They recently closed an issue to add auto-formatting >> https://github.com/jscs-dev/node-jscs/issues/516 >> In theory, you could create a script to autoformat your code and write it >> in any style that appears comfortable to you. It would be useful for >> someone to explore this and comment back on results. >> >> We should be wasting less time on the appearance of code - making sure it >> adheres to standards - and instead focusing on the contents of its code. >> >> >> >> On Wed, Oct 14, 2015 at 9:39 AM, Tim Landscheidt >> wrote: >> >>> dinar qurbanov wrote: >>> i think i lose my individuality and that i have to make extra key presses to set extra spaces near brackets and commas. currently tests / automatical reviews show in gerrit that my commit has such errors. what if they are not (would not be? were not? ) blamed on commit (patch set) uploads, but only automatically prettified/standartised at/before actual commit/merge? >>> and, by the way, i think, should not they even be saved as they are written and should not, instead, diff tools automatically standartise them before calculating difference? >>> >>> How would it help the reviewer if they constantly need to >>> switch their mind from "prettified" code to "whatever" when >>> they review your code? >>> >>> If you don't want to press the space bar, you can always in- >>> tegrate stylize >>> ( >>> http://git.wikimedia.org/blob/mediawiki%2Ftools%2Fcode-utils.git/master/stylize.php >>> ) >>> in your workflow or amend your editor to insert the spaces >>> when you type. >>> >>> Tim >>> >>> >>> ___ >>> Wikitech-l mailing list >>> Wikitech-l@lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> >> >> >> -- >> Jon Robson >> * http://jonrobson.me.uk >> * https://www.facebook.com/jonrobson >> * @rakugojon >> ___ >> 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.
[Wikitech-l] 2015-10-14 Scrum of Scrums meeting notes
https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-10-24 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Fwd: READ: Any/All deployments CANCELED rest of the week
FYI regarding updates to WMF production the rest of the week. - Forwarded message from Greg Grossmeier - > Date: Wed, 14 Oct 2015 11:46:17 -0700 > From: Greg Grossmeier > To: Development and Operations engineers , > Operations Engineers > Subject: READ: Any/All deployments CANCELED rest of the week > > Due to two days in a row of outages while the Ops team is at their > offsite this week we (Mark and I) have decided to cancel ALL deployments > for the rest of the week. > > "ALL? Like even ?" Yes, even that. No new code. No config changes. > No rolling of the train. We'll clean up the current situation and then > we'll be staying there until next week. > > Any questions please contact me (Mark is no very contactable, > obviously). > > > -- > | Greg GrossmeierGPG: B2FA 27B1 F7EB D327 6B8E | > | identi.ca: @gregA18D 1138 8E47 FAC8 1C7D | - End forwarded message - -- | 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] i would like that i need not set standart spacing in my code
>Apologies for the bluntness, but if you cannot conform to the coding standards >of a project in terms of minor things such as spacing, how can we know or >trust you that you are confirming to standards that are more meaningful, such >as those related to security? ... we are talking about changing the standarts themselves. so the current standarts will not be standarts any more after they are changed. having different styles will be ok then. >Standards allow for a consistent appearance of the codebase both on an >aesthetic and functional level. On the aesthetic side of things, we strive for >code that is easy for humans to read and understand in order to assist in code >reviews. ... as i said, if there were special support from gerrit, they would appear consistent. on the aesthetic side, just consistency of code through whole of code is not enough, because different people want different style, everyone by his/her preference. > ... consider merging in changes to someone else's work -- if your style > clashes with theirs the result will look horrible ... as i said , there are solutions for that : a) main code may have consistent code and only new commit/merge preparations have inconsistent code b) only code in authors/programmers/coders' (local) computers may keep their own styles, being automatically standartised when accepted by server c) even main code may keep inconsistent styles, and git, svn, etc diff/ patch/ merge tools can automatically standartise code on fly for every operation. too bad or strange codes like too many chars in line or too many spaces or incorrect indendation may still be forced to fix by authors themselves. 2015-10-14 21:11 GMT+03:00 Ryan Schmidt : > Apologies for the bluntness, but if you cannot conform to the coding > standards of a project in terms of minor things such as spacing, how can we > know or trust you that you are confirming to standards that are more > meaningful, such as those related to security? > > Standards allow for a consistent appearance of the codebase both on an > aesthetic and functional level. On the aesthetic side of things, we strive > for code that is easy for humans to read and understand in order to assist in > code reviews. Having a single defined standard to achieve that also adds a > level of consistency and professionalism to the codebase. While I personally > believe MediaWiki's style is too spacey, I understand the value in having all > code conform to the standard and as a result I conform to it when coding for > MediaWiki. I encourage you to look for and understand the value of a single > standardized style as well as opposed to each developer coding however it > suits them. > > On the technical side of things, consider merging in changes to someone > else's work -- if your style clashes with theirs the result will look > horrible and as a result be harder to read and understand. And if someone > else comes back and makes an edit in somewhere slightly nearby, you'll have > to deal with annoying merge conflicts due to whitespace issues instead of git > just intelligently merging it all together automatically. > > On Oct 14, 2015, at 10:42 AM, dinar qurbanov wrote: > >>> How would it help the reviewer if they constantly need to >>> switch their mind from "prettified" code to "whatever" when >>> they review your code? >> >> it is possible to show prettified code in gerrit web pages, and send >> prettified version to people if they get it via git fetch, but save >> also their original form . >> >> and, as another alternative, it is possible to save original form in >> author's computer, and automatically prettify it in gerrit server just >> after he pushes it into gerrit... >> >>> If you don't want to press the space bar, you can always in- >>> tegrate stylize >>> ( >>> http://git.wikimedia.org/blob/mediawiki%2Ftools%2Fcode-utils.git/master/stylize.php >>> ) >>> in your workflow or amend your editor to insert the spaces >>> when you type. >> >> then i would need to see that prettified code at my further local >> editions and sometimes i would have to manually delete that extra >> spaces during editing my code. >> >> >> >> >> 2015-10-14 20:23 GMT+03:00 Jon Robson : >>> FYI if you are talking about JavaScript you might want to explore >>> http://jsbeautifier.org/ >>> >>> All code standards are currently being enforced by jscs. >>> They recently closed an issue to add auto-formatting >>> https://github.com/jscs-dev/node-jscs/issues/516 >>> In theory, you could create a script to autoformat your code and write it >>> in any style that appears comfortable to you. It would be useful for >>> someone to explore this and comment back on results. >>> >>> We should be wasting less time on the appearance of code - making sure it >>> adheres to standards - and instead focusing on the contents of its code. >>> >>> >>> >>> On Wed, Oct 14, 2015 at 9:39 AM, Tim Landscheidt >>> wrote: >>> dinar qurbanov wrote: > i th
Re: [Wikitech-l] i would like that i need not set standart spacing in my code
On Wed, Oct 14, 2015 at 10:42 AM, dinar qurbanov wrote: > it is possible to show prettified code in gerrit web pages, and send > prettified version to people if they get it via git fetch, but save > also their original form . > It really isn't. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] i would like that i need not set standart spacing in my code
On Wed, Oct 14, 2015 at 12:07 PM, Gergo Tisza wrote: > On Wed, Oct 14, 2015 at 10:42 AM, dinar qurbanov wrote: > > > it is possible to show prettified code in gerrit web pages, and send > > prettified version to people if they get it via git fetch, but save > > also their original form . Also, we want to ditch Gerrit, not add more cruft to it. -- 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] i would like that i need not set standart spacing in my code
On Wed, Oct 14, 2015 at 11:57 AM dinar qurbanov wrote: > >Apologies for the bluntness, but if you cannot conform to the coding > standards of a project in terms of minor things such as spacing, how can we > know or trust you that you are confirming to standards that are more > meaningful, such as those related to security? ... > > we are talking about changing the standarts themselves. so the current > standarts will not be standarts any more after they are changed. > having different styles will be ok then. > > There should always be standards. Even if we manage them somewhere else so programmers can avoid writing in-style themselves, we still have to have an actual standards to enforce :) > > ... consider merging in changes to someone else's work -- if your style > clashes with theirs the result will look horrible ... > > as i said , there are solutions for that : a) main code may have > consistent code and only new commit/merge preparations have > inconsistent code b) only code in authors/programmers/coders' (local) > computers may keep their own styles, being automatically standartised > when accepted by server That's actually an option. Also, `arc` allows us to handle this semi- automagically when we start moving more towards Phabricator for our CR. It would allow people to focus less on writing pretty code, although it would let them know prior to pushing that their commit had been rewritten. > c) even main code may keep inconsistent > styles, and git, svn, etc diff/ patch/ merge tools can automatically > standartise code on fly for every operation. too bad or strange codes > like too many chars in line or too many spaces or incorrect > indendation may still be forced to fix by authors themselves. > > The server-side code has to be the same. Different whitespace would result in different diffs and sha1s and completely different underlying repos in Git. Any changes to coding style have to be done client-side. If you really want to rewrite MW's coding style to your own, you could probably get away with a post-checkout hook in your git repo. That would let you look at MW code with all the ugly spaces removed :) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] GSoC 2016 Announced
Hi everybody, I just had a discussion with the GSoC program admin: Carols and she said that the GSoC program for 2016 has been announced. Date of announcement is: 13th Oct, 2015. You can have a look at the news here for more information like the timeline - Timeline: https://developers.google.com/open-source/gsoc/timeline - Announcement: https://developers.google.com/open-source/gsoc/ Will keep you all posted if i get to have any information about this and up coming issues. Good luck to all prospective GSoC participants. Its on and hoping to see what Wiki will do this time around :) -- Regards Alangi Derick Ndimnain ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Google Mail marking Phabricator and Gerrit notification emails as spam
You can whitelist mails from wikimedia.org via gmail's web interface: http://email.about.com/od/gmailtips/qt/et_whitelist.htm Am 14.10.2015 um 19:35 schrieb Greg Grossmeier: > Just FYI for those on Google-hosted email. > > See: https://phabricator.wikimedia.org/T115416 > > TL;DR: Check your spam folder :) > > Greg > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] i would like that i need not set standart spacing in my code
dinar qurbanov wrote: >> How would it help the reviewer if they constantly need to >> switch their mind from "prettified" code to "whatever" when >> they review your code? > it is possible to show prettified code in gerrit web pages, and send > prettified version to people if they get it via git fetch, but save > also their original form . > and, as another alternative, it is possible to save original form in > author's computer, and automatically prettify it in gerrit server just > after he pushes it into gerrit... >> If you don't want to press the space bar, you can always in- >> tegrate stylize >> ( >> http://git.wikimedia.org/blob/mediawiki%2Ftools%2Fcode-utils.git/master/stylize.php >> ) >> in your workflow or amend your editor to insert the spaces >> when you type. > then i would need to see that prettified code at my further local > editions and sometimes i would have to manually delete that extra > spaces during editing my code. > [...] You could also amend your editor to do those deletions for you, but I think there is a fundamental misunderstanding here: MediaWiki is a collaborative project. If you think in categories like "author" and "my" or "your" code, you will be disappointed. MediaWiki uses a very spacey coding style, other PHP projects do not. Even though the syntax is /very/ similar, most C, JavaScript, Perl, PHP, etc. projects use different conventions. So: When in Rome, do as the Romans do. Every- thing else does not work in practice. Tim ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] i would like that i need not set standart spacing in my code
On Wed, Oct 14, 2015 at 10:23 AM, Jon Robson wrote: > All code standards are currently being enforced by jscs. > They recently closed an issue to add auto-formatting > https://github.com/jscs-dev/node-jscs/issues/516 There's also the --fix flag to jscs, which automatically fixes whitespace-only failures. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] PHP CodeSniffer is now voting on MediaWiki core patches
Hi, On 09/26/2015 04:28 PM, Legoktm wrote: > There are still a few code style rules that are disabled, [2] is > tracking fixing those issues. These have all been resolved, and all rules in the MediaWiki standard are now passing and voting \o/ > [2] https://phabricator.wikimedia.org/T102609 -- Legoktm ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] 2015-10-14 Scrum of Scrums meeting notes
Corrected link: https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-10-14 On Wed, Oct 14, 2015 at 11:25 AM, Grace Gellerman wrote: > https://www.mediawiki.org/wiki/Scrum_of_scrums/2015-10-24 > ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] PHP CodeSniffer is now voting on MediaWiki core patches
*yay* thanks for the work! :) Gesendet mit meinem HTC - Nachricht beantworten - Von: "Legoktm" An: "Wikimedia developers" Betreff: [Wikitech-l] PHP CodeSniffer is now voting on MediaWiki core patches Datum: Do., Okt. 15, 2015 01:13 Hi, On 09/26/2015 04:28 PM, Legoktm wrote: > There are still a few code style rules that are disabled, [2] is > tracking fixing those issues. These have all been resolved, and all rules in the MediaWiki standard are now passing and voting \o/ > [2] https://phabricator.wikimedia.org/T102609 -- Legoktm ___ 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] i would like that i need not set standart spacing in my code
On 10/14/2015 10:53 PM, Jon Robson wrote: > FYI if you are talking about JavaScript you might want to explore > http://jsbeautifier.org/ Yes. And if you are using an IDE(Example: atom), there are extensions that will beautify your code as per a defined jsbeautify configuration on file save or manual trigger. Here is a sample jsbeautifier configuration that match with our JavaScript coding conventions https://github.com/wikimedia/mediawiki-extensions-ContentTranslation/blob/master/.jsbeautifyrc -- Santhosh Thottingal http://thottingal.in ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
