07:16:35 #startmeeting 52nd Mahara Developer Meeting 07:16:35 Meeting started Thu Apr 28 07:16:35 2016 UTC and is due to finish in 60 minutes. The chair is anitsirk. Information about MeetBot at http://wiki.debian.org/MeetBot. 07:16:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 07:16:35 The meeting name has been set to '52nd_mahara_developer_meeting' 07:16:40 Welcome to our 52nd Mahara developer meeting. Please say who you are and prefix that with "#info" so that the meeting minutes pick it up. 07:16:47 #info anitsirk is Kristina Hoeppner, Catalyst, Wellington in New Zealand 07:16:49 #info robertl_ is Robert Lyon, Catalyst in Wellington, New Zealand 07:16:54 #info aaronw_ is Aaron Wells, Catalyst IT, Wellington NZ 07:17:35 #info Yair Spielmann, Synergy Learning, in Belfast, Northern Ireland 07:17:37 #info ghada is Ghada El-Zoghbi, Catalyst IT, Sydney, Australia 07:17:41 #info Gregor_Pirker is Gregor Pirker, Danube University Krems, Krems, Austria 07:17:53 #topic Items from last meeting 07:17:54 #info since both mingard and anzeljg aren't here (yet), we'll postpone their items until later or next time. 07:18:08 So onto our first new agenda item 07:18:08 #topic Drop support for PHP 5.3? 07:18:13 aaronw_: all yours 07:18:31 Just wondering if we want to drop support for PHP 5.3 in the next Mahara release 07:18:49 the next being 16.04 or 16.10? 07:18:51 Unfortunately I have not collated the latest data from mahara.org/stats as I'd intended to... 07:18:54 16.10 07:18:59 no objection to this on my part 07:19:21 well seeing as php7 is upon us now 07:19:45 And we just had some PHP 5.3 compatibility bugs a couple of weeks ago 07:19:46 we should definitely consider dropping active support for 5.3 07:20:03 but if a patch is given by community 07:20:10 and it's small easy fix 07:20:12 right, i thought the min was PHP5.5 already 07:20:14 then include it 07:20:30 some redhat I think uses 5.3 07:20:38 ghada: strangely enough there are still a few places out there tied to PHP 5.3, because they're running RHEL 6.7 07:20:52 or the CentOS equivalent 07:21:06 earlier this month we had to fix some bugs for two separate institutions on 5.3 07:21:16 #idea drop support for PHP 5.3 officially in Mahara 16.10. It is getting old. 07:21:36 There was also this on the forums: https://mahara.org/interaction/forum/topic.php?id=7529&offset=30 07:21:42 Alright, it sounds like amongst us devs there is not much love for 5.3 07:21:43 it was because he was using php5.3 07:21:46 do we know when RHEL 6.7 becomes obsolete? 07:22:08 I think it is possible to get newer versions of PHP on RHEL 6.7 07:22:16 you have to add some additional software repositories 07:22:24 yes you can. but it's a pain 07:22:33 we had to do it for one of our clients. it wasn't fun 07:22:40 hm 07:22:51 6.7 is still under extended support until July 2017 07:23:29 oh, another consideration is that some of our dependencies are starting to drop support for 5.3 07:23:43 #info some of our dependencies are starting to drop support for 5.3 07:23:43 Specifically, I noticed it in one of the PEAR libraries 07:24:17 ah true - so us supporting 5.3 might end up being unattainable anyway 07:24:31 yep 07:25:02 anitsirk: Any thoughts? 07:25:40 if some of our dependies drop support, shouldn't we take the approach we did for IE? 07:25:47 what's that? 07:25:50 or rather similar approach 07:25:57 not support it anymore when it's not supported? 07:26:22 oh, well, PHP 5.3 has actually been out of support from Zend for several years now 07:26:22 we could still fix issues as robertl_ noted if people provide patches but we would not actively support such an old system anymore 07:26:40 since August 2014 07:26:46 http://php.net/eol.php 07:26:48 alex from synergy was asking me about php7 support just recently. so we need to find a balance there. 07:27:09 most similar open-source packages I've seen have stopped 5.3 support also. 07:27:14 yeah, dropping 5.3 support would make our "support" burden smaller, since now we also have to start worrying about PHP 7 support 07:27:33 okay, so let's say we're dropping support for 5.3 in 16.10, unless we come across some big reason to keep it 07:27:57 I'm for that 07:28:46 sounds good to me 07:28:46 next topic? 07:29:00 yep. let me just take note of the decision 07:29:26 #agreed Drop support for php 5.3 in 16.10, unless we come across some big reason to keep it. 07:29:36 #topic Switch to PSR-2 coding standard? 07:29:45 aaronw_: you again 07:29:57 Yep, sorry guys, I put a few hefty topics on this one. ;) 07:30:07 http://www.php-fig.org/psr/psr-2/ 07:30:24 So, PSR-2 is the most widely used PHP code formatting standard 07:30:31 shared by several prominent PHP projects 07:31:16 I think it would be good if we switched from Mahara's individual coding standard to that one 07:31:16 thoughts? 07:31:47 "Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body." 07:31:53 how much effort would it be to update existing code to the standard? 07:31:55 wow... that's going to confuse Moodle 07:31:59 Moodle devs 07:32:14 it already does 07:32:26 Yep, no more confusing than our current standard ;) 07:32:33 I guess as an alternative, we could adopt the Moodle coding standard 07:32:47 No... please don't 07:32:48 that's actually my preferred format. braces on new lines. 07:32:56 no, not Moodle 07:33:03 oh, good 07:33:03 PSR-2 is much nicer 07:33:16 yeah, and PSR-2 will have better tool support 07:33:18 (And consider JS coding style too) 07:33:18 I've had to make a few adjustments over the past few years for those braces! 07:33:33 dobedobedoh do you know if there's a PSR-2 equivalent, for Javascript? 07:33:44 I prefer it on the same line (but admittedly I am mostly a Moodle dev, so slightly biased here) 07:33:46 Not off the top of my head - there are loose standards but no spec 07:34:04 something we could do, also, is to put a formatter step into our Makefile 07:34:15 so, that would ease things a bit 07:35:00 aaronw_: yes the formatter is a great idea 07:35:37 oh why!!!! "Opening braces for control structures MUST go on the same line, and closing braces MUST go on the next line after the body." 07:35:49 did we lost anitsirk? 07:38:12 well, if we go with PSR-2 we will have to embrace cuddled elses again :) 07:39:38 hmm, people seem to be dropping out 07:39:44 kristina can't get into the chat room 07:40:10 I guess we will pause for a few minutes 07:40:30 whoops, disconnected for a second there 07:40:30 sweet they are back 07:40:36 did I miss anything? 07:40:45 ah, you're back! 07:40:50 sorry. i was lost in IRC space. 07:40:58 second computer to the rescue (for now). 07:41:17 is the bot still on? 07:41:20 last message I saw was dobedobedoh at 7:33:50? 07:41:40 the bot is showing some error messages in its logs... 07:41:57 but it seems like it's still connected 07:42:17 oh, seems like everyone is getting kicked off 07:43:00 who's still here? 07:43:07 I am 07:43:09 i'm here 07:43:10 at the moment i don´t have any problems :-) 07:43:13 i am 07:43:24 i am 07:43:49 have we lost sl-yair ? 07:43:51 aaronw_: was asking about moving to the psr-2 coding standard and what your thoughts were. any discussion on that yet? 07:44:08 i think it's a good idea. 07:44:24 just need to figure out how long it will take to change the cod 07:44:25 code 07:44:28 I think it is a good idea also 07:44:39 and effort involved... 07:44:43 ghada: good question about the bot. if it's not, we can run the log through it later 07:44:59 well, I'd like to just bite the bullet, run an autoformatter on all the existing code (excluding external libraries) and commit in one big commit 07:45:03 that would be not much effort at all 07:45:10 #info good idea to move to widely recognized coding standards. we'll need to assess the effort needed to do so. 07:45:30 #idea run an autoformatter on all the existing code (excluding external libraries) and commit in one big commit 07:45:32 plus it'll give me a lot of "lines changed" for the next release ;) 07:45:40 lol 07:45:47 cheater 07:45:56 another thing we could do to ease the transition is put a formatter step into the Makefile 07:46:00 That's ok. we're going to have to go in and fix it after 07:46:15 aaronw_: should we coordinate that with jen who's reviewing mochikit and effort needed there for stripping it out (taking jono's patch into consideration)? 07:46:18 ;-) 07:46:39 Well, this formatting change shouldn't affect the MochiKit thing 07:46:51 but it might be good to ask Jen if she has any suggestions on a JS code formatting standard 07:47:46 okay, sounds like we're decided. I'll file a Launchpad bug for the format change. 07:48:02 still here 07:48:44 #action aaronw to file a bug to switch to the PSR-2 coding standard 07:48:58 alright and because there are three things to everything: 07:49:03 the problem with reformatting everything is that it could really mess up the git history 07:49:04 #topic Namespaces and autoloading 07:49:08 presented by ? 07:49:13 aaronw_ :-) 07:49:15 the formatter in the Makefile is also good idea 07:49:23 and my third topic! 07:49:48 I'd like to move all of Mahara's library code into namespaces, so we can use an autoloader 07:49:48 and rebasing core customisations would be a disaster 07:50:13 #idea move all of Mahara's library code into namespaces, so we can use an autoloader 07:50:20 yes, one downside to changing the code format is that it'll make it harder to apply patches 07:50:44 it's just whitespace changes, though, so it shouldn't be too big of a problem 07:51:00 #info one downside to changing the code format is that it'll make it harder to apply patches. it's just whitespace changes, though, so it shouldn't be too big of a problem 07:51:19 back to namespaces... 07:51:50 in 16.04dev, Robert while investigating performance issues, found that we were loading the artefact/lib.php and a whole bunch of artefact libraries, on every single page load 07:51:54 usually unnecessarily 07:52:02 so he removed that, to improve performance 07:52:32 but then it turned out that there was a lot of code that wanted to call get_artefact_descendants(), from artefact/lib.php, and didn't have the proper require()'s, because previously it'd been loaded on every single page 07:52:39 namespace and autoloader would be a very welcome addition i.m.o 07:52:43 if we switched to an autoloader system, it would let us resolve problems like that 07:53:02 so basically, the way this would go is that we'd put all of our library files under namespace \Mahara 07:53:12 and then artefacts would be \Mahara\Artefact, etc 07:53:40 and then we could register an autoloader, that would automatically know which PHP file to load, based on the namespace and our file layout 07:53:51 thus removing our need for most require() statements 07:54:08 #idea so basically, the way this would go is that we'd put all of our library files under namespace \Mahara and then artefacts would be \Mahara\Artefact, etc and then we could register an autoloader, that would automatically know which PHP file to load, based on the namespace and our file layout thus removing our need for most require() statements 07:54:25 unfortunately there's no autoloader for standalone functions, so I would also like to move all the standalone functions like artefact_get_descendants into static functions of a utility class, so they could be autoloaded too 07:54:46 like, artefact_get_descendants would become \Mahara\ArtefactUtil::artefact_get_descendants() or some such 07:54:55 #info unfortunately there's no autoloader for standalone functions, so aaronw_ would also like to move all the standalone functions like artefact_get_descendants into static functions of a utility class, so they could be autoloaded too 07:55:07 for backwards compatibility we could provide a compatibility library that maps the standalone function names to the new static functions 07:55:21 #idea for backwards compatibility we could provide a compatibility library that maps the standalone function names to the new static functions 07:55:29 so, that's the whole thing 07:55:33 thoughts? 07:55:50 third party plugins 07:55:54 would that mean turning group/lib.php into a class as well? 07:55:59 they'll have to make the change as well 07:56:15 as I keep expecting it should be 07:56:17 yeah, all the functions under group/lib.php would be moved into static functions of a utility class 07:56:34 then I'm all for it :) 07:56:43 #info third-party libraries would need to make the change as well. 07:56:50 hm, will have to give some thought to 3rd-party libraries... 07:56:59 #undo 07:56:59 Removing item from minutes: 07:57:15 it would be best not to require them to be massively rewritten 07:57:27 I'll think about that 07:58:15 if we provided that backwards-compatibility library that provides wrapper functions around the namespaced functions... similarly I guess we could provide BC non-namespaced classes? 07:58:39 something like "class ArtefactType extends \Mahara\Artefact\ArtefactType {};" 07:58:56 #action aaronw_ to think about how a change to namespaces would affect 3rd-party libraries and whether they'd need to move to namespaces as well. 07:59:47 okay, I'll file a Launchpad bug, and make sure not to move forward until we've figured out how to avoid breaking 3rd-party libraries 07:59:59 any other thoughts on this topic? 08:00:37 well, since we're going to be formatting, there will be lots of changes in the code. 08:00:44 when Moodle introduced autoloader, it allowed a couple of transition versions in which third party plugins could behave as before if they wanted. 08:00:48 this will be another change - which is not a bad thing 08:01:04 thanks sl-yair, I'll take a look at how Moodle handled it 08:01:30 #action aaronw_ to file a bug around namespaces. but no changes will be made until we have a solution to avoid breaking 3rd-party libraries as best as possible 08:01:31 (in fact they still technically can, but it's frowned upon) 08:01:49 #info Moodle faced a similar issue and provided a couple of transition versions in which third party plugins could behave as before if they wanted. 08:02:14 anything else? 08:02:50 ok. then i'm just throwing in a new topic because i can as chair. ;-) it's too important to just come under "Any other business" 08:02:52 we don't keep anything in the db do we ? 08:03:03 like location of a class or something crazy like that? 08:03:26 just the names of classes 08:03:27 sorry anitsirk 08:03:48 nah. go ahead, ghada 08:03:55 so wouldn't that be affected? 08:03:56 i.e. blocktype_installed expects the names of the blocktypes to correlate to the directory of the blocktype and the name of the class 08:04:08 nope 08:04:19 ok. 08:04:22 we'll just correlate the namespaced name of the class in the same way 08:04:26 and the sitedata should be all good. 08:05:01 i hope.. 08:05:57 all good? 08:06:08 i think so. 08:06:11 thanks anitsirk 08:06:22 #topic Mahara 16.04 release 08:06:42 So, the champagne or tequilla, whichever is your vice, is cooled, but needs to cool its heals a bit longer 08:06:50 i still need to finish the release notes. 08:07:11 aaronw_: i sent you a draft to review. if you are ok with them, i'll just add the sponsors and I'm good to go if you are 08:07:19 alright! 08:07:47 #info This release is a nice small one but does have some cool new features. 08:07:49 http://manual.mahara.org/en/16.04/genindex.html#N 08:07:57 the big one is HTML5 media player 08:08:08 thanks to ZHAW in switzerland which sponsored that. 08:08:32 #info we also integrated the Open Badges displayer plugin that discendum had developed. it's now in core. 08:08:54 #info the big feature is HTML5 media player, which ZHAW in switzerland sponsored. 08:09:13 take a look in the manual to see all the new / changed features that users can experience 08:09:47 #info I also gave a presentation on the big new features last week https://slides.com/anitsirk/count-down-to-mahara-1604 (in the recording it starts at around minute 4) 08:10:03 so thank you very much to everybody who's contributed to this release. 08:10:19 we were able to include some nice long-wished for features (including wall notifications!) 08:10:48 oh, cron protection. nice. 08:10:54 if the packaging has been done (aaronw_?) we will release tonight. 08:11:04 yep, it's done 08:11:13 sl-yair: yes. nice but also annoying during testing. fortunately, there is a way to turn it off for that. :-) 08:11:18 aaronw_: cool. thanks. 08:13:16 so yes. that'll be 16.04 for you. 08:13:46 #info the release of 16.04 also means that support for 1.10 is dropped. we will have one more minor point release for that version but not more. 08:14:42 great work again by everyone making mahara better! 08:15:03 yes, good work you guys 08:15:03 That brings me to the next topic 08:15:24 #topic Next meeting and chair 08:15:45 What about 26 May at the same time? That would be a thursday again 08:15:49 http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160526T07 08:16:28 sure, that works for me 08:16:35 same 08:16:51 time sounds fine to me 08:17:09 Gregor_Pirker and sl-yair: does that work for you up north? 08:17:39 up west, the later the better 08:18:03 huh? you are not in europe? 08:18:38 for me sound good time and date 08:18:58 N. Ireland 08:19:00 I am. sorry, I mostly commented on the timezone :) But most people here seem to be in NZ so waking up a bit early is fine. 08:19:41 8 am too early? 08:20:28 we could probably do 9 a.m. green isles which should be 8 p.m. NZ if aaronw_ and robertl_ are ok with that and it also works for the others 08:20:32 to have it an hour later 08:20:56 I could do that 08:21:24 that would be great 08:21:55 ghada, robertl_ and Gregor_Pirker would one hour later work for you? http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160526T08 08:22:54 It´s okay for me :-) 08:23:16 yep 08:23:46 ok. who wants to be chair? :-D 08:25:09 #info the 53rd Mahara developer meeting will take place on 26 May 2016 at 8:00 UTC and anitsirk will be chairing the meeting. http://www.timeanddate.com/worldclock/fixedtime.html?iso=20160526T08 08:25:13 all sorted. 08:25:18 #topic Any other business 08:26:07 I can have one 08:26:20 fire away! 08:26:32 So, earlier I said to postpone anzeljg's action item "will try to create some plans/wireframes for simplifying Mahara create page procedure" 08:26:40 but actually, i can speak to that :-) 08:27:20 #info alja, a UX designer who works with anzeljg, has come up with some wireframes and ideas that I'll put together with our current ideas and upload within the next two weeks. 08:27:52 it's been great to get her perspective on mahara as she hadn't used it before. some things were similar, others not and getting something out to the wider community will be great to gather wider feedback. 08:28:07 have to go now, thanks guys, it has been a very good meeting. 08:28:07 we already implemented at least one small change following on from the discussions the two of us had. 08:28:12 so watch this space. 08:28:24 bye sl-yair. thanks for joining in. 08:28:31 CU some other time. 08:28:40 Any other small items? 08:28:46 CU! 08:29:31 doesn't look like it. or maybe some people got dropped again. so let's finish for tonight / morning. 08:29:36 :-) I can give you a little bit feedback from our Partners: The Mahara 15.10 is very nice designed and userfriendly and they like it very much ;-) 08:29:44 right. go ahead, Gregor_Pirker 08:30:00 well, that's good to hear 08:30:04 fantastic. good to read. patk and the other front-end devs will be happy to hear that. 08:30:37 #info feedback from the partners in the european portfolio project: The Mahara 15.10 is very nice designed and userfriendly and they like it very much 08:30:45 big feedback can i give you in october then startet the schools in the projekt ;-) 08:30:57 that sounds great. 08:31:22 definitely have a chat with anzeljg and alia before then in case you want to make some changes to test with different default parameters for your users 08:31:55 we can discuss that in july in vienna as well :-) 08:32:08 anything else? 08:32:18 oh yes. 08:32:26 :-) 08:32:53 #info aaronw_ resurrected the script that allows pulling translations from git into the langpack site so that we now have the up-to-date czech translation in 08:33:10 aaronw_: would that actually also help with the german "du" translation that we can't do via launchpad? 08:33:26 but we can discuss that next week seeing that it's getting late. 08:33:36 oh, yeah, I guess it could 08:34:32 cool. let's discuss that then. 08:35:02 #action anitsirk to discuss the german "du" translation with aaronw_ and whether git would be the solution to make the up-to-date translation available. 08:35:15 alright. i think that's really it now. 08:35:17 going once 08:35:31 going twice 08:35:40 the end 08:35:42 #endmeeting