[Wikitech-l] The return of the Weekend Sprint to 1.17
Last week I promised you I would return to beating the 1.17 tarball drum. So let the beating begin. The first batch of bugs is focused on the new installer. Chad, Raimond, Max, and others have all been working on getting this in shape, but a few bugs still remain. We really need to get these cleared out before we release a tarball since this will be the first thing most people see. [Installer] Javascript-opened sections not open on back or error http://bugzilla.wikimedia.org/26937 [Installer] Install does not complete when choosing a CC license http://bugzilla.wikimedia.org/27170 [Installer] $*Key values sometimes not filled http://bugzilla.wikimedia.org/26481 [Installer] Chrome saves config as LocalSettings.php.php http://bugzilla.wikimedia.org/27579 [Installer] Cannot abort or postpone slow operations during upgrades via web interface http://bugzilla.wikimedia.org/27929 Installer doesn't create extension tables http://bugzilla.wikimedia.org/28237 Installer does not respect initial DBport declaration http://bugzilla.wikimedia.org/28162 Labels for DB types on page=DBConnect are too narrow http://bugzilla.wikimedia.org/28158 While most people do stick with MySQL, a fair number of rebels install the other major Open Source database: PostgreSQL. We focus our own development on MySQL, but not having support for PostgreSQL would be pretty embarrassing. As a result, these bugs are fairly important. Greg has likely fixed the first one, Chad has started looking at the second one, but the third is wide open. Postgres install fails with no schema http://bugzilla.wikimedia.org/28171 Error on Postgres install - wfGetDB called when it shouldn't http://bugzilla.wikimedia.org/28172 Postgres defaults to a unix socket - mention in install? http://bugzilla.wikimedia.org/28173 If layout and javascript are more your thing, we have a couple of those left, too: width of gallery always 100% http://bugzilla.wikimedia.org/27540 New wikilink window grows in width each time when opened in IE and Chrome http://bugzilla.wikimedia.org/27566 Finally, a bonus 1.17 blocker. Tim has suggested two separate ways to solve the problem. Should we go with the “simple” fix or the ”complex” fix? Truth be told, at this point, we can probably only afford the simple one. Apostrophe in linktrail breaks bolded links http://bugzilla.wikimedia.org/27473 Happy Hacking! Mark. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code Review tools
On 26/03/11 05:48, Daniel Friesen wrote: What about the fixmes left open since it's not clear if anything is even still broken currently. If it is unclear: it either need a clarification or deserve a reversion. We already have enough lines hiding in the fog, read to jump at you when you get out of the path. The fixmes for things like extra things like new tests should be added, but the actual commit in question isn't broken in any way. The fixmes for things which are perfectly functional, but need a minor bit of tweaking since they work perfectly find, but don't use the best practice methods to do it. Do we even have fixmes for the last two cases? Anyway for tests, they might be required just to make sure other developers using the feature will use it as intended. There are always funny corner cases to handle, specially with PHP. -- Ashar Voultoiz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code Review tools
2011/3/26 Mark A. Hershberger mhershber...@wikimedia.org: If code is to survive past a week in the repository, it has to be reviewed. This is basically what I suggested in the other thread, except I added a few other conditions that have to be satisfied before we can start using such a paradigm (relating to reviewer allocation, discipline and assignment). Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] feedback on gsoc proposal
Hi All,
My name is ankit. I am applying for Gsoc 2011 .I have prepared an
initial draft for the proposal(copied below) .I have taken feedback from my
mentor Yaron Koren on this. Please feel free to give your comments ..
Thanks
Gsoc proposal for Semantic Schemas
Short summary: Semantic Schemas a proposed extension , that would let users
and admins define everything about the wiki's data structure via XML
contained within wiki pages. That XML in turn would be used to generate all
the other relevant pages: templates, properties, forms, etc. And the XML
would be editable via a helper form, so that ideally users would never have
to do direct XML editing. Also, the XML could theoretically be imported
from, and exported to, other data-structure formats, like OWL and UML.
About me
My name is Ankit Garg . I am first year student of Computer Science
department , SKIT Jaipur, India. I am interested in applying for google
summer of code 2011. I am quite new to the open-source community and still
exploring it. I have been involved in MediaWiki development under the
guidance of Yaron Koren and have already done few projects in Semantic
MediaWiki.
I want to do this project because It will give me an opportunity to work
with a large open-source community so that I can learn more about it . I am
a passionate programmer . I have done programming in various languages
including C++,Java, PHP, Javascript , etc. I liked the idea that was
proposed by Yaron Koren to build a new Semantic MediaWiki extension namely
Semantic Schemas. with successful completion of my projects with Yaron on
MediaWiki gave me a good idea about the Semantic MediaWiki code-base and the
prospects of the proposed extension. I think it will be very useful to many
users who are using SMW and are looking for a common platform which combines
all the SMW extensions in a more manageable way.
== Some contributions to MediaWiki=
1) Extension UrlGetParams :
The extension didn't have support for array parameters, like if you have
?a[b]=c, there was no way to display c on the page. Modified the
extension to accept array parameters now . now u can write
{{#urlget:a[key]|default-value))
2)Extension:ReplaceText
(
http://www.mediawiki.org/wiki/Extension_talk:Replace_Text#Regex_.28big_wish.29
)
added regular expression support for the extension . Now a user can type
regular expression for both search and replace patterns.
for eg. a(.*)b into search string and ab$1 into replacement string,
and then each instance of acb would change into abc.
3)Calender format in Semantic Result Formats
calendar' format, which lets users display dates in a calendar. Some
people wanted to be able to change the first day of the week to something
other than Sunday
I added a fix for supporting any day as the first day in the calender
view.
Deliverables
1) Create a new extension, Semantic Schemas, that parses the defined
Semantic Schemas XML structure and stores it in memory, and provides hooks
for other extensions to add their own elements to the XML.
2) Add code to other extensions (most likely Semantic MediaWiki, Semantic
Forms and Semantic Drilldown) to add parsing for additional XML elements,
using those hooks.
3) Add to Semantic Schemas a simple mechanism for displaying the XML to
users.
4) Add a special page to Semantic Schemas, Special:GenerateClassPages,
that lets users generate a set of wiki pages based on the XML in one page.
5) Add code to other extensions to create specific page types when
GenerateClassPages is called: Semantic Forms (would create templates and
forms), Semantic MediaWiki (would generate property pages) and Semantic
Drilldown (would generate filter pages).
6) Add another special page to Semantic Schemas, Special:EditSchema, that
lets users create and edit the XML using a form.
Project schedule
1. 15th May: Getting to know the community.
2. 24th May- :- Programming Begins.
3. 23rd July:- Finishing at least 4 deliverables.
4. 23rd August : Project complete, with full documentation.
--
Ankit Garg
Student @ SKIT
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Enable WikiTrust spanish support
2011/3/25, Platonides platoni...@gmail.com: Wilfredor wrote: If we could support this on our existing server, it should not be too much work for us to set it up. I would like to know the exact format of the ids you need (The order and the necessary parameters for each line of the csv) and if there is a system to add What is the correct mechanism or methodology to build this list? I think it should be just a wiki page containing a list. Pageids can be easily extracted later. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Enviado desde mi dispositivo móvil Wilfredo Rafael Rodríguez Hernández msn,googletalk = wilfre...@gmail.com cv = http://www.wilfredor.co.cc blog = http://wilfredor.blogspot.com fotos = http://picasaweb.google.com/wilfredor/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FIXME: Wall of Shame
Original Message - From: K. Peachey p858sn...@gmail.com Since we havn't done one of these in awhile, a wall of shame for fixmes, If it looks weird, copy it into a plain text editor. (I believe you've mispelt get a real email client. :-) Cheers, -- jra ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code Review tools
On 11-03-25 11:57 PM, Ashar Voultoiz wrote: On 26/03/11 05:48, Daniel Friesen wrote: What about the fixmes left open since it's not clear if anything is even still broken currently. If it is unclear: it either need a clarification or deserve a reversion. We already have enough lines hiding in the fog, read to jump at you when you get out of the path. The fixmes for things like extra things like new tests should be added, but the actual commit in question isn't broken in any way. The fixmes for things which are perfectly functional, but need a minor bit of tweaking since they work perfectly find, but don't use the best practice methods to do it. Do we even have fixmes for the last two cases? Anyway for tests, they might be required just to make sure other developers using the feature will use it as intended. There are always funny corner cases to handle, specially with PHP. I pretty much described all my commits with a fixme tagged on them: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/81928 Waiting for me to have some time to turn uses of echo into $this-output so that the built in --quiet will work, instead of my own custom implementation of --quiet (I didn't know -output existed). http://www.mediawiki.org/wiki/Special:Code/MediaWiki/80248 Comment gives a Tesla link saying something broke. However the Tesla link does not identify that commit as the guaranteed commit that actually broke code. The commit was followed up with several fixmes already and it's unknown if the breakage is still present. The commit is potentially perfectly functional, hit by Tesla catching a completely unrelated commit, or marking a bug that's already fixed. http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79639 Perfectly functional, just waiting for me to have time to add a small parser test for the behavior. http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79433 Of all my fixmes this one is the most bug like... that being said, it's an if() anyone could add I haven't had time to do. http://www.mediawiki.org/wiki/Special:Code/MediaWiki/79383 The commit is perfectly functional, SkinTemplateNavigation and SkinTemplateTabs existed before and after the commit, I just replaced SkinTemplateTabs with SkinTemplateNavigation. The fixme is for the fact that Legacy skins are still using a hack that uses SkinTemplateTabs that also needs to be updated... which, to be honest isn't a good reason to revert a commit, it's pretty much orthogonal to the functionality of the commit. ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code Review tools
Daniel Friesen wrote: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/80248 Comment gives a Tesla link saying something broke. However the Tesla link does not identify that commit as the guaranteed commit that actually broke code. The commit was followed up with several fixmes already and it's unknown if the breakage is still present. The commit is potentially perfectly functional, hit by Tesla catching a completely unrelated commit, or marking a bug that's already fixed. Come on. It is easy enough to check if your revision is the culprit. svn up -r r80247 cd tests/phpunit/ make noparser There was 1 failure: 1) NewParserTest::testParserTests Bad images - basic functionality (failed: Bad images - basic functionality There were 9 incomplete tests: 1) ApiUploadTest::testUpload RandomImageGenerator: dictionary file not found or not specified properly 2) ApiUploadTest::testUploadSameFileName RandomImageGenerator: dictionary file not found or not specified properly 3) ApiUploadTest::testUploadSameContent RandomImageGenerator: dictionary file not found or not specified properly 4) ApiUploadTest::testUploadStash RandomImageGenerator: dictionary file not found or not specified properly 5) ApiTest::testApiGotCookie The server can't do external HTTP requests, and the internal one won't give cookies 6) ApiWatchTest::testWatchEdit Broken 7) ApiWatchTest::testWatchProtect Broken 8) ApiWatchTest::testWatchRollback Only one author to 'UTPage', cannot test rollback 9) ApiWatchTest::testWatchDelete Broken There were 2 skipped tests: 1) ApiTest::testApiListPages This test depends on ApiTest::testApiGotCookie to pass. 2) ApiWatchTest::testWatchClear This test depends on ApiWatchTest::testWatchEdit to pass. cd ../.. svn up -r r80248 cd tests/phpunit/ make noparser There were 2 errors: 1) ApiBlockTest::testMakeNormalBlock htmlspecialchars() expects parameter 1 to be string, object given 2) NewParserTest::testFuzzTests MWException: Out of memory: -- There were 3 failures: 1) TitlePermissionTest::testQuickPermissions Failed asserting that two arrays are equal. --- Expected +++ Actual @@ @@ Array ( [0] = Array ( [0] = badaccess-groups -[1] = *, [[Local:Users|Users]] +[1] = *, Users [2] = 2 ) ) 2) TitlePermissionTest::testPageRestrictions Failed asserting that two arrays are equal. --- Expected +++ Actual @@ @@ Array ( [0] = Array ( [0] = badaccess-groups -[1] = *, [[Local:Users|Users]] +[1] = *, Users [2] = 2 ) [1] = Array ( [0] = protectedpagetext [1] = bogus ) [2] = Array ( [0] = protectedpagetext [1] = protect ) [3] = Array ( [0] = protectedpagetext [1] = protect ) ) 3) NewParserTest::testParserTests Bad images - basic functionality (failed: Bad images - basic functionality Failed asserting that text is equal to string:. Bad images - basic functionality) Failed asserting that boolean:false is true. So r80248 did break three tests. cd ../.. svn up cd tests/phpunit php phpunit.php includes/api/ApiBlockTest.php OK (1 test, 4 assertions) php phpunit.php includes/TitlePermissionTest.php There was 1 failure: 1) TitlePermissionTest::testUserBlock Failed asserting that two arrays are equal. This is a different test, which expects infinite and now returns a Message Object. The problem was fixed in trunk. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code Review tools
Roan Kattouw wrote: 2011/3/26 Mark A. Hershberger mhershber...@wikimedia.org: If code is to survive past a week in the repository, it has to be reviewed. This is basically what I suggested in the other thread, except I added a few other conditions that have to be satisfied before we can start using such a paradigm (relating to reviewer allocation, discipline and assignment). Roan Kattouw (Catrope) You mentioned reverting broken code. Mark proposes reverting *unreviewed* code. We are generally polite by marking fixme the code from others, and avoiding reverting as much as possible. I agree with the proposal of reverting after a few days with an important fixme. But reverting new revisions because noone reviewed it, seems going too far (at least at this moment). It would make much more sense to draft some process where you have to review the previous revision of the files you are changing. However, that would forbid fast fixes (eg. fixing the whitespace of the previous commit) without fully reviewing it, which is also undesirable (the revision keeps unreviewed, and with the wrong whitespace). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FIXME: Wall of Shame
K. Peachey wrote: ├───┼┴───┴─┤ │ 7 │ platonides ├┬───┬─┤ │ │ r70498 │ trunk/phase3/includes │ 14:37, 5 August 2010│ That's Bug 25355. Blaming this revision seemed a good guess, but the problem reported in CodeReview does not happen in mediawiki.org although this revision is in 1.17wmf1 │ │ r70900 │ trunk/phase3/includes/parser │ 17:11, 11 August 2010 │ │ │ r74159 │ trunk/extensions/ArticleComments/ArticleComments.php │ 21:45, 2 October 2010 │ It's a this should be improved further kind of fixme. │ │ r80025 │ trunk/phase3/includes/parser/Parser.php │ 18:38, 11 January 2011 │ Was fixed in r80065 │ │ r81896 │ trunk/phase3 │ 16:39, 10 February 2011 │ It restores the db2 behavior previous to r80892. I let ^demon fix it ;) │ │ r82874 │ trunk/phase3/tests │ 23:36, 26 February 2011 │ Was fixed in r82874 │ │ r84429 │ trunk/extensions/PoolCounter/daemon │ 20 March 2011 │ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Meaning of fixme (Re: code review criticism (Re: Converting to Git?))
Ilmari Karonen wrote: This made me realize something that's only tangentially related to the existing thread, namely that we're currently using the fixme status in Code Review for two different kinds of commits: 1. commits that are broken and need to be fixed or reverted ASAP, and 2. commits that do more or less work, but need some followup work. An example of the first kind of commit would be something that throws PHP fatal errors on a substantial fraction of page views. An example of the second kind might be something as minor as forgetting to update RELEASE_NOTES. Of course, there's also a wide range of shades of gray between these two extremes, such as changes that work most of the time but break some unusual setups or use cases. Still, I do think that most fixme commits can be fairly cleanly assigned to one or the other of these categories, simply by asking oneself Can I run a usable wiki with this code as it is? I think it might be a good idea to split these two cases into separate states. My suggestion, off the top of my head, would be to leave fixme for the latter and add a new broken status for the former. +1 We should also add another state for fixmes that are not about problems in the revision itself, but request for improving more code (eg. you should fix the same thing -added in MW 1.4- in other 10 locations of the code, too). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Code Review tools
Roan Kattouw wrote: 2011/3/26 Mark A. Hershberger mhershber...@wikimedia.org: If code is to survive past a week in the repository, it has to be reviewed. This is basically what I suggested in the other thread, except I added a few other conditions that have to be satisfied before we can start using such a paradigm (relating to reviewer allocation, discipline and assignment). A number of people, for quite some time, have been urging MediaWiki code development to get back to the Brion/Tim style of revert if broken. I'm certainly among them, so I'm thrilled to see this discussion finally happening. Next step is action. :-) In addition to the other benefits, more regular reverts will (hopefully) reduce the stigma of being reverted. The wiki model has always encouraged boldness, but it has also equally encouraged the ability to pull back changes as necessary. The tendency to not revert nearly as much made a reversion a much bigger deal, from what I've seen. Even more so (or perhaps exclusively so) when it has involved paid work (i.e., work done by Wikimedia Foundation employees/contractors). A move toward more reverts, as long as it doesn't discourage new or old contributors, is definitely the way forward, I think. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FIXME: Wall of Shame
On Sat, Mar 26, 2011 at 11:33 PM, Jay Ashworth j...@baylink.com wrote: Original Message - From: K. Peachey p858sn...@gmail.com Since we havn't done one of these in awhile, a wall of shame for fixmes, If it looks weird, copy it into a plain text editor. (I believe you've mispelt get a real email client. :-) Cheers, -- jra It's longer than 80 characters wide, so some real clients will still display it wrong. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] FIXME: Wall of Shame
- Original Message - From: K. Peachey p858sn...@gmail.com (I believe you've mispelt get a real email client. :-) It's longer than 80 characters wide, so some real clients will still display it wrong. Fair point. Why I always ran mutt in an xterm. :-) Cheers, -- jra ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
