Re: [Wikitech-l] ExtensionDistributor
On 06/08/10 15:11, Jeroen De Dauw wrote: Hey, I figured I can use the same code as ExtensionDistributor for creating packages for the deployment extensions. The code for creating archives and going through the svn repo is not in the extensions directory on svn as far as I can determine though. Where can I find it? If it's not publicly available anywhere at the moment, can it be made so? I'm not sure which bit you're missing, but it's all documented at: http://wikitech.wikimedia.org/view/ExtensionDistributor -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ExtensionDistributor
Hey, I'm not sure which bit you're missing, but it's all documented at: The code that creates the tarballs. Cheers -- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! -- On 6 August 2010 08:25, Tim Starling tstarl...@wikimedia.org wrote: On 06/08/10 15:11, Jeroen De Dauw wrote: Hey, I figured I can use the same code as ExtensionDistributor for creating packages for the deployment extensions. The code for creating archives and going through the svn repo is not in the extensions directory on svn as far as I can determine though. Where can I find it? If it's not publicly available anywhere at the moment, can it be made so? I'm not sure which bit you're missing, but it's all documented at: http://wikitech.wikimedia.org/view/ExtensionDistributor -- Tim Starling ___ 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] ExtensionDistributor
We won't release the code since it's not GPL Regards, Wikipedia Staff On Fri, Aug 6, 2010 at 9:53 AM, Jeroen De Dauw jeroended...@gmail.com wrote: Hey, I'm not sure which bit you're missing, but it's all documented at: The code that creates the tarballs. Cheers -- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! -- On 6 August 2010 08:25, Tim Starling tstarl...@wikimedia.org wrote: On 06/08/10 15:11, Jeroen De Dauw wrote: Hey, I figured I can use the same code as ExtensionDistributor for creating packages for the deployment extensions. The code for creating archives and going through the svn repo is not in the extensions directory on svn as far as I can determine though. Where can I find it? If it's not publicly available anywhere at the moment, can it be made so? I'm not sure which bit you're missing, but it's all documented at: http://wikitech.wikimedia.org/view/ExtensionDistributor -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Interlanguage Extension - going on
2010/8/6 Nikola Smolenski smole...@eunet.rs: I have recently fixed some of its shortcomings (see https://bugzilla.wikimedia.org/show_bug.cgi?id=15607#c41 and onward) and I believe that the extension is now ready for practical use. Could anyone interested review the code and see if it is technically good enough, and if there is anything else that needs to be done? And if it is good enough and there is nothing critical missing, what would be the steps to test it in the real world and actually deploy it? When it has passed review, I suppose we could set up a few wikis at prototype.wikimedia.org and test it there. It was originally set up for the usability initiative but it seems to be used for increasingly random testing purposes now, and we have no other proper place for this. - Reading the links from a foreign database instead of via the API. Is there a proper way to do this? Yes. You can obtain a connection to a foreign DB with wfGetDb( DB_SLAVE, array() 'wikiID' ); . Both the wiki ID and the API URL can be obtained from the interwiki table now (that is, there are fields for them, we're not actually filling those fields yet), as part of Peter's work on the iwtransclusion branch for GSoC. How have you been obtaining API URLs anyway? - Updating links on dependent wikis when deleting, undeleting etc. articles on the central wiki. This is something the iwtransclusion branch also has to address. The current plan is to do that using a global templatelinks table. - Purging the pages on dependent wikis via the API, or smarter way of purging without the API. Why does purging via the API require login, when purging the usual way does not? That's a bug in the API purge module; I'll fix it later today. Again, the iwtransclusion branch also needs to take care of purging. There's no code for it yet, but I don't think it involves more than updating page_touched in the remote DB and notifying Squid. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ExtensionDistributor
2010/8/6 Jax cybercorecen...@gmail.com: We won't release the code since it's not GPL Regards, Wikipedia Staff This person is not associated with WMF in any way, so please ignore their message. The code that creates the tarballs is right there in ExtensionDistributory_body.php , line 208 and below. Simply grepping the source for 'tar' would've shown that. Interestingly, none of the ExtensionDistributor files have GPL headers. This should probably be fixed. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Interlanguage Extension - going on
On 08/06/2010 11:51 AM, Roan Kattouw wrote: 2010/8/6 Nikola Smolenskismole...@eunet.rs: I have recently fixed some of its shortcomings (see https://bugzilla.wikimedia.org/show_bug.cgi?id=15607#c41 and onward) and I believe that the extension is now ready for practical use. Could anyone interested review the code and see if it is technically good enough, and if there is anything else that needs to be done? And if it is good enough and there is nothing critical missing, what would be the steps to test it in the real world and actually deploy it? When it has passed review, I suppose we could set up a few wikis at prototype.wikimedia.org and test it there. It was originally set up for the usability initiative but it seems to be used for increasingly random testing purposes now, and we have no other proper place for this. Great! :) Note that, for testing purposes, it is possible to keep the pages of the central wiki in a separate namespace or as subpages. - Reading the links from a foreign database instead of via the API. Is there a proper way to do this? Yes. You can obtain a connection to a foreign DB with wfGetDb( DB_SLAVE, array() 'wikiID' ); . Both the wiki ID and the API URL can be obtained from the interwiki table now (that is, there are fields for them, we're not actually filling those fields yet), as part of Peter's work on the iwtransclusion branch for GSoC. How have you been obtaining API URLs anyway? I'm using $wgInterlanguageExtensionApiUrl variable that has to be set in LocalSettings.php - Updating links on dependent wikis when deleting, undeleting etc. articles on the central wiki. This is something the iwtransclusion branch also has to address. The current plan is to do that using a global templatelinks table. Interlanguage extension was lucky in that the articles that need to be updated are exactly the ones that the interwikis link to :) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Testing Framework (was Selenium Framework - Question on coding conventions)
On Thu, 05 Aug 2010 18:47:58 -0400, Mark A. Hershberger wrote: Markus Glaser gla...@hallowelt.biz writes: 1) Where are the tests located? I suggest for core to put them into maintenance/tests/selenium. That is where they are now. For extensions I propse a similar structure, that is extensiondir/tests/selenium. Sounds fine. In the same way, since maintenance/tests contains tests that should be run using PHPUnit, we can say that extensiondir/tests will contain tests that should be run using PHPUnit. Alternatively, we could use the word Selenium somewhere in there in order to be able to divide between unit and selenium tests. I think putting them in the selenium directory (or the “Se” directory) is sufficient. 3) How does the framework know there are tests? Can I suggest that the framework can see that an extension has tests simply by the presence of the extensiondir/tests directory containing a Extension*TestSuite.php file? The extensiondir/tests/ExtensionTestSuite.php file should define a class using the name ExtensionTestSuite which has a static method suite(). See the PHPUnit documentation at http://bit.ly/b9L50r for how this is set up. This static suite() method should take care of letting the autoloader know about any test classes so the test classes are only available during testing. So, for your example using PagedTiffHandler, there would be the files: PagedTiffHandler/tests/PagedTiffHandlerTestSuite.php PagedTiffHandler/tests/PagedTiffHandlerUploadsTestSuite.php 4) Which tests should be executed? By default all the test suites in extensiondir/tests should be run. It is should be possible to specify which particular test to run by using whatever command line arguments to the CLI. This seems better to me than defining a new global. If some tests should only be run rarely, that information can be put in the TestSuite class for te extension. In this way, I think it is possible to remove all the $wgSelenium* variables from the DefaultSettings.php file. (I plan to do something similar with the $wgParserTest* variables as well — these sorts of things don't seem like they belong in Core.) Mark. I don't think walking through all the extensions looking for test subdirectories and then running all tests therein is a good idea. First, in a large installation with many extensions, this takes time and delays the test execution. Second, if a developer is working on a particular extension or part of the core, it will be common to run the tests associated with that for regression purposes. Making the developer specify the extension or core tests to run on the RunSeleniumTests command line is irritating (at least, it would irritate me). Specifying the test suite(s) to be run in LocalSettings.php is a set and forget approach that allows the developer to get on with the work. However, I do agree that the number of global variables associated with the selenium framework is getting large and has the potential of growing over time. One solution is to use a multi-dimensional associative array (much like $wgGroupPermissions). We could use a global variable $wgSelenium and move all selenium framework values into it. For example: $wgSelenium['wiki']['host'] = 'localhost'; $wgSelenium['wiki']['wikiurl'] = false; $wgSelenium['wiki']['loginname'] = 'Wikiuser; $wgSelenium['wiki']['password'] = ''; $wgSelenium['server']['port'] = ; etc. The only global we may wish to keep separate is $wgEnableSelenium, since it specifies whether $wgSelenium is used. -- -- Dan Nessett ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Selenium Framework - Question on coding conventions
On 05.08.2010, 20:37 Markus wrote: 1) Where are the tests located? I suggest for core to put them into maintenance/tests/selenium. That is where they are now. For extensions I propse a similar structure, that is extensiondir/tests/selenium. 2) How are the tests organized? Tests are organized in testing suites. Each suite represents a conhesive set of tests. So it is possible to have more than one test suite per extension / core area. Test suites are technically classes. The files should follow this naming convention: NameOfExtension[Subset]TestSuite.php. The subset is optional. For example, in the PagedTiffHandler extension, it would be PagedTiffHandlerTestSuite.php and PagedTiffHandlerUploadsTestSuite.php. This should also be the name of the class. Alternatively, we could use the word Selenium somewhere in there in order to be able to divide between unit and selenium tests. In that case I suggest to use PagedTiffHandlerSeleniumTestSuite.php and PagedTiffHandlerUploadsSeleniumTestSuite.php. Hmmm... this gives pretty long names. Any suggestions? 3) How does the framework know there are tests? The tests should be registered with the autoloader in the extension entry file. In core, they should be registered directly with the autoloader. I've already implemented a system allowing extensions to register their PHPUnit tests with UnitTestsList hook, and it's much more simple: a couple of lines on extension's side and one wfRunHooks() call in the test runner. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] prototype vs. test (was: Interlanguage Extension - going on)
2010/8/6 Roan Kattouw roan.katt...@gmail.com When it has passed review, I suppose we could set up a few wikis at prototype.wikimedia.org and test it there. It was originally set up for the usability initiative but it seems to be used for increasingly random testing purposes now, and we have no other proper place for this. Just curious: There's also http://test.wikipedia.org/ . What's the difference between it and prototype? I know that prototype has different language versions and i'm not sure about test in this regard. And except that? -- אָמִיר אֱלִישָׁע אַהֲרוֹנִי Amir Elisha Aharoni http://aharoni.wordpress.com We're living in pieces, I want to live in peace. - T. Moore ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] prototype vs. test (was: Interlanguage Extension - going on)
When it has passed review, I suppose we could set up a few wikis at prototype.wikimedia.org and test it there. It was originally set up for the usability initiative but it seems to be used for increasingly random testing purposes now, and we have no other proper place for this. Just curious: There's also http://test.wikipedia.org/ . What's the difference between it and prototype? I know that prototype has different language versions and i'm not sure about test in this regard. And except that? Test is a part of the cluster. Prototype is not. We have more flexibility on what we can put on prototype versus test. V/r, Ryan Lane ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] prototype vs. test (was: Interlanguage Extension - going on)
On Fri, Aug 6, 2010 at 11:21 AM, Ryan Lane rlan...@gmail.com wrote: Test is a part of the cluster. Prototype is not. We have more flexibility on what we can put on prototype versus test. Prototype is also used exclusively by the Usability Team, while testwiki is the normal Developer/Sysadmin Test Wikipedia. Before the Wikimedia sysadmins do a scap/major code rollout, they first roll-out the code changes to testwiki to verify everything works in the regular Wikimedia environment. -- Casey Brown Cbrown1023 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] prototype vs. test (was: Interlanguage Extension - going on)
2010/8/6 Casey Brown li...@caseybrown.org: Prototype is also used exclusively by the Usability Team This is no longer strictly true. I have been creating prototype wikis for the flaggedrevs folks and WMDE, and I expect more such random wikis to follow. , while testwiki is the normal Developer/Sysadmin Test Wikipedia. Before the Wikimedia sysadmins do a scap/major code rollout, they first roll-out the code changes to testwiki to verify everything works in the regular Wikimedia environment. This is true, and this, not usability team exclusivity, is the important difference here. testwiki is really only for things that we deem ready to go live and want to check one more time before we accidentally let a typo wreck stuff, so code that goes there has to be pretty solid already. prototype is a completely separate machine that we can play around with to our heart's content, so mostly we can just throw stuff on there and see what happens. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Testing Framework (was Selenium Framework - Question on coding conventions)
On Fri, 06 Aug 2010 12:38:39 -0400, Aryeh Gregor wrote: On Thu, Aug 5, 2010 at 6:47 PM, Mark A. Hershberger m...@everybody.org wrote: Can I suggest that the framework can see that an extension has tests simply by the presence of the extensiondir/tests directory containing a Extension*TestSuite.php file? IMO, the way parser tests do it is smarter. When you install the extension, it adds the location of the test files to $wgParserTestFiles. That way, only the tests associated with installed extensions will run. If you want to force only particular tests to run all the time, you can also modify the variable in LocalSettings.php as usual. We are doing something similar. In the extension require() file, the test suite is added to $wgAutoloadClasses. Right now the entry in $wgSeleniumTestSuites is pushed in LocalSettings. However, we could establish the convention that it is pushed in the extension require() file as well. Then all extensions with test suites would automatically load them. To tailor this, the entries in $wgSeleniumTestSuites could be removed in LocalSettings. -- -- Dan Nessett ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Flash and other proprietary technologies on Wikimedia projects
Flash is evil. Also, I'm a little confused what you are trying to accomplish in flash that you can't do in HTML. To do a WYSIWYG editor, you would need to make sure the editing interface is being rendered exactly the same as the viewing interface. You will be constantly trying to mimic the way HTML is rendered in a browser. This seems like a difficult task that has nothing to do with editing wikitext. - Trevor On 8/4/10 7:22 PM, Alex Zariv wrote: On Wed, Aug 4, 2010 at 7:04 PM, Casey Brownli...@caseybrown.org wrote: On Wed, Aug 4, 2010 at 6:59 PM, Guillaume Paumier gpaum...@wikimedia.org wrote: A few relevant links for a historical perspective: Another, somewhat more recent one: http://wikimediafoundation.org/wiki/Minutes/October_3-5,_2008#Open_Standards_.2F_Free_File_Formats The board asked Sue to have Mike Godwin revise the draft policy to a version that would make it clear that only free formats are permissible. Did that ever happen? (Or did anything useful ever come about of it?) There was also a proposed policy on Meta: http://meta.wikimedia.org/wiki/File_format_policy, but it looks like it's historical now. Alex ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Testing Framework (was Selenium Framework - Question on coding conventions)
I think /tests/unit and /tests/acceptance would be reasonable places to put things, and if they are both within maintenance or in the root doesn't really matter to me. Remember Selenium is a framework for doing acceptance testing, not unit testing. I don't quite see the purpose of specifying the framework name in our directory structure. Are we planning on using more than one unit or acceptance testing framework? My 2 cents. - Trevor On 8/5/10 3:55 PM, Chad wrote: On Thu, Aug 5, 2010 at 6:47 PM, Mark A. Hershbergerm...@everybody.org wrote: Markus Glasergla...@hallowelt.biz writes: 1) Where are the tests located? I suggest for core to put them into maintenance/tests/selenium. That is where they are now. For extensions I propse a similar structure, that isextensiondir/tests/selenium. Sounds fine. In the same way, since maintenance/tests contains tests that should be run using PHPUnit, we can say thatextensiondir/tests will contain tests that should be run using PHPUnit. I would prefer moving them to a subdirectory of /tests/. As we hopefully amass more unit tests, keeping them in the top-level will get a bit confusing when trying to distinguish them from supporting code (shared setUp and tearDown code, the bootstrap stuff, etc) Something like /maintenance/tests/unit/ to mirror /maintenance/tests/ selenium/ would make the most sense. Consistency and thinking ahead is nice :) -Chad ___ 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] Selenium Framework - Question on coding conventions
On 8/5/10 9:37 AM, Markus Glaser wrote: Hello everybody, in order to further develop the selenium framework [1], I need to make a few design decisions, especially on coding conventions, which I'd like to discuss on this list, since they affect the way of how extension- and core developers write their tests. 1) Where are the tests located? I suggest for core to put them into maintenance/tests/selenium. That is where they are now. For extensions I propse a similar structure, that isextensiondir/tests/selenium. 2) How are the tests organized? Tests are organized in testing suites. Each suite represents a conhesive set of tests. So it is possible to have more than one test suite per extension / core area. Test suites are technically classes. The files should follow this naming convention:NameOfExtension[Subset]TestSuite.php. The subset is optional. For example, in the PagedTiffHandler extension, it would be PagedTiffHandlerTestSuite.php and PagedTiffHandlerUploadsTestSuite.php. This should also be the name of the class. Alternatively, we could use the word Selenium somewhere in there in order to be able to divide between unit and selenium tests. In that case I suggest to use PagedTiffHandlerSeleniumTestSuite.php and PagedTiffHandlerUploadsSeleniumTestSuite.php. Hmmm... this gives pretty long names. Any suggestions? In PHPUnit a TestSuite is a class is a class that orchestrates the execution of many Test classes, so PagedTiffHandlerTest would exercise the PagedTiffHandler class, but ImagePagingHandlersTestSuite might conduct tests for PagedTiffHandler and also PdfHandler or whatever. 3) How does the framework know there are tests? The tests should be registered with the autoloader in the extension entry file. In core, they should be registered directly with the autoloader. PHPUnit uses either a TestSuite class to determine what to run, or an XML file. Explicitly listing each test is not neesecary to run all tests, but TestSuite classes or XML defined suites help run a portion of tests. I don't know if Selenium supports this kind of functionality, but it would be nice if we could find a similar approach between the two frameworks. 4) Which tests should be executed? Since Selenium tests are slow, not every test should be executed in each test run. So At the moment, there is a variable $wgSeleniumTestSuites which can be set in LocalSettings.php and which contains the tests that should be run. If things become more dynamically (e.g. when tests should be run on svn commit), there could be a function to add to this variable. 5) Aesthetics... There is an awful lot of Selenium in the class names, method names, file names and variable names. It might be a good idea to use Sn everywhere except for path names. PHP 5.3 namespaces? (with backslashes! -- evil music --) Two things need to be kept in mind: * The idea is to use a similar structure for unit- and selenium tests (selenium tests are based on unit tests anyway). I assume at some point, the tests should also be compatible with a continuous integration server. * The wiki that executes the selenium tests is not neccesarily the one that is being tested if the tests run against a selenium grid. If anybody would like to share their opinion on my suggestions, I'd be very glad! Regards, Markus [1] http://www.mediawiki.org/wiki/SeleniumFramework (documentation will be updated soon..) ___ 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] ExtensionDistributor
Thanks Roan, I'm wondering how I could have missed that :) Cheers -- Jeroen De Dauw * http://blog.bn2vs.com * http://wiki.bn2vs.com Don't panic. Don't be evil. 50 72 6F 67 72 61 6D 6D 69 6E 67 20 34 20 6C 69 66 65! -- On 6 August 2010 12:02, Roan Kattouw roan.katt...@gmail.com wrote: The code that creates the tarballs is right there in ExtensionDistributory_body.php , line 208 and below. Simply grepping the source for 'tar' would've shown that. Interestingly, none of the ExtensionDistributor files have GPL headers. This should probably be fixed. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
Marco Schuster wrote: On Fri, Aug 6, 2010 at 1:08 AM, Platonides platoni...@gmail.com wrote: Other patches are not so fine... wfSuppressWarnings(); - session_start(); + @session_start(); wfRestoreWarnings(); Sure, it was for FusionForge package, but still what error would session_start produce that is not trapped? (I can only make an E_NOTICE or E_WARNING...) It's enough to break later header(); with Can't send header information - headers already sent by in foo. Marco The point is, both of them are suppressed by wfSuppressWarnings... So what can the @ be suppressed that wfSuppressWarnings may have missed? Unless the decision to add an @ there predates out own warning supppresion. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] ExtensionDistributor
Jax wrote: We won't release the code since it's not GPL Regards, Wikipedia Staff You have three contributions to this mailing list, ranging from trolling to impersonating WMF Staff. Unless you can somehow excusate your behavior, I recommend your posting rights to be revoked. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] How to package (was: Debian packages (was MediaWiki version statistics) )
Tim Starling wrote: Does anyone see a problem with that approach? The web installer should not be a part of installation from a package at all. We should just get the wiki name from debconf, use the system locale as the language, and install it with defaults otherwise. Then the user will have a working wiki after install. -- Tim Starling I disagree. Existing packages do try to install it in /mediawiki or so, leaving it half-configured for the user to finish by running the web installer but that's not smart. IMHO installing the mediawiki package should provide you with a command like install-mediawiki which would request the location and setup all the server alias needed. On 06/08/10 09:10, Platonides wrote: My idea for a FHS-friendlier setup was based in storing the LocalSettings for all installed wikis inside /etc/mediawiki.d, all of them pulling from a CommonSettings.php where default overrides and extensions affecting all installs would be stored. That's basically what it does already, but it does it by patching the setup code. I'd rather see a distributed LocalSettings.php file which pulls in the necessary sub-config files. That can be done without any changes to our source. Oh, you mean distributed as in the package? That's another option.Other than the different instructions needed, debian_specific_config.patch could be done by playing with ENV vars. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to package (was: Debian packages (was MediaWiki version statistics) )
On Fri, Aug 6, 2010 at 5:40 PM, Platonides platoni...@gmail.com wrote: Tim Starling wrote: Does anyone see a problem with that approach? The web installer should not be a part of installation from a package at all. We should just get the wiki name from debconf, use the system locale as the language, and install it with defaults otherwise. Then the user will have a working wiki after install. -- Tim Starling I disagree. Existing packages do try to install it in /mediawiki or so, leaving it half-configured for the user to finish by running the web installer but that's not smart. IMHO installing the mediawiki package should provide you with a command like install-mediawiki which would request the location and setup all the server alias needed. New installer should fix a lot of this. We'll be including a CLI installer in 1.17, which dpkg or whatever could call to handle the DB setup, etc. Shouldn't need to use the web installer *at all* at that point. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to package (was: Debian packages (was MediaWiki version statistics) )
On 6 August 2010 22:40, Chad innocentkil...@gmail.com wrote: New installer should fix a lot of this. We'll be including a CLI installer in 1.17, which dpkg or whatever could call to handle the DB setup, etc. Shouldn't need to use the web installer *at all* at that point. \o/ THANK YOU, from the bottom of my crusty intranet sysadmin heart. - d. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] How to package (was: Debian packages (was MediaWiki version statistics) )
On Fri, Aug 6, 2010 at 5:40 PM, Platonides platoni...@gmail.com wrote: I disagree. Existing packages do try to install it in /mediawiki or so, leaving it half-configured for the user to finish by running the web installer but that's not smart. IMHO installing the mediawiki package should provide you with a command like install-mediawiki which would request the location and setup all the server alias needed. Getting the info from debconf seems like it makes much more sense than having a separate command you have to run. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Debian packages (was MediaWiki version statistics)
On Fri, Aug 6, 2010 at 5:16 PM, Platonides platoni...@gmail.com wrote: The point is, both of them are suppressed by wfSuppressWarnings... So what can the @ be suppressed that wfSuppressWarnings may have missed? Unless the decision to add an @ there predates out own warning supppresion. @ must not be used, ever. Any uses you see are wrong and should be refactored. The vast majority of offenders are lazy array index accessing: BAD PROGRAMMER: $foo = @$bar['key']; GOOD PROGRAMMER: $foo = isset( $bar['key'] ) ? $bar['key'] : null; It's a few extra keystrokes, but you're saved from using the @ to suppress *all* errors that could be occurring there--not just the possible index-does-not-exist. Better example: $foo = @$this-obj-bar['key']; If you use @, you're also suppressing that $obj might not be an object, or that $bar doesn't have a key 'key'. Another common pitfall might be: @$obj-method(); What happens if method() changes and nobody checked the callers? You're now possibly suppressing errors you never meant to suppress. What sort of errors are ok to suppress, and how do I do it? The most common (and annoying) errors that need suppression are file operation things (fopen, file_get_contents, etc), usually due to invalid permissions. If you want to hide errors here, it's ok to do something like: wfSuppressWarnings(); $t = file_get_contents( 'somefile' ); wfRestoreWarnings(); This will properly suppress and restore the warnings for you. Handy trick, if you're making directories, wfMkdirParents() handles all of this for you, so you can just check the boolean return without having to worry about possible errors. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
