Developer meeting October 2015
From MoodleDocs
Developer meetings > October 2015 meeting notes
| Time | 07:00 UTC on Wednesday, 21 October 2015 Add to my calendar |
| Meeting room | Live stream at YouTube |
| Forum discussion | Thread in GDF at moodle.org |
| Chat | Jabber dev chat |
| #moodledev | |
| Social event page | Google+ event page |
| Meeting notes | devpad |
Agenda
Upcoming changes in Moodle 3.0
- Summary of changes in Moodle 3.0 from Moodle contributor's perspective (both core and plugins development), overview of most important upgrade.txt notes. Presented by Damyon Wiese (Moodle HQ), Marina Glancy (Moodle HQ).
- MDL-51213 Safely callable external_format_text() - Damyon Wiese (Moodle HQ).
- MDL-51107 Ability to inject nodes in the category settings navigation - Frederic Massart (Moodle HQ).
- MDL-49329, MDLSITE-4203 Plugins management improvements and impact on plugins versioning schemes - David Mudrák (Moodle HQ).
Moving towards PHP7
- Short overview of PHP7 benefits and required changes.
- MDL-50565, MDL-51011, MDL-51155 Sharing experience with work started on adding support for PHP7 - Eric Merrill (Oakland University), Tony Levi (NetSpot).
Travis-CI integration
- MDL-51458 Benefits of Travis-CI for developers and how to set things up so that you can use it during your moodle development - Andrew Nicols (Moodle HQ)
Meeting notes
Upcoming changes in Moodle 3.0 APIs (Damyon)
- Biggest changes, upgrades to some major libraries
- Zend - haven't been upgraded in several years
- Not full Zend, mainly used for web services only
- Looking at options of getting rid of Zend. It's big, 12MB of code and not much of it is used
- Zend - haven't been upgraded in several years
- Web service
- Improved AJAX support
- Ability to declare that WS needs/does not need the session
- Changed way to mark when functions are safe to be called via web services
- Created db/services.php file
- Question: is this now available for 3rd party plugins to create these calls? I think previously only core code could create them
- A: Yes, any plugin's db/services.php can do that.
- However, it is a pain having docs not next to the code. That is why PHPdocs are right by the function it documents. There are risks in the plan here.
- YUI
- SimpleYUI had a bug which is particularly noticable in our brave new world of requireJS modules
- SimpleYUI had its own instance of Y; this was particularly problematic for events, as they are constrained to their Y instance - now there is one instance of Y no matter where you're using it
- Get local referrer (HTTP_REFERER -> get_local_referer())
- More secure
- Learning plans for compentency based learning objectives
- Not in 3.0, but major work is going on and will be in a future version
- Some depecrated functions are now safe to be removed
- Question: What's the roadmap for 3.1? The next LTS release
- Competency based education is the major feature -
- Waiting for Moodle Association to provide some input on projects to work on
- Major takeway
- From point of view of plugin developers, 3.0 is a stable release with small improvements which doesn't impact making changes from 2.9 to 3.0
- Check upgrade.txt files for API changes
PHP 7 support in Moodle
- [1]
- Official notes on PHP 7 migration are at [2]
- Libraries need updating
- Get issues fixed upstream and update to new versions where possible
- Some are more difficult due to no newer versions and/or heavy customisation, eg Quickforms
- Question: Refresh forms library, does that mean abandoning QuickForms? For what library? From stratch? Is there a dev doc?
- Given how long we have been talking about this, this is not a valid plan for PHP7 support.
- The most likely plan will be to add patches as required for php7 to the exising quickforms - and look at options for either extending or replacing it (options need to be properly evaluated - it is a bigger project)
- Abandoning QuickForms might not be the best course of action at first. Perhaps a combination of upstream patches (php constructors) and extensions to it (mustache integration, ajax etc)
- Catalyst had a blog post showing ~15% performance improvement. [3]
- Logging in is 2x faster over PHP 5.6
- Performance is major incentive for many larger sites to upgrade faster than usual to newest version
- I was wondering how their comparison tests would look like if they had opcache enabled
- Biggest issue
- Deprecated PHP4 contructors, lots of warnings - PHPunit will always fail
- Eg, break inside an if statement will create a fatal error
- Question (from dev chat):do you find that cpu usage a bottleneck on moodle sites? (not saying that we shouldn't be doing it ASAP, I just am concerned that we need to be careful about the message which is sent to the community DP)
- For us (NetSpot) the main reason this is interesting is to get responses to users much faster - 250ms starts to feel "snappy"
- DB not much of an issue since MUC + some of our own important core changes
- For us (Oakland U) CPU is the largest bottleneck, but even so, PHP7 sig deacreases perceived lag.
- Ahh, thats very interesting - it's important for the 'percieved speed'. I have always been thinking we are always DB limited -Dan
- (Also have always imagined its much easier to beef up frontend performance with parraellisation)
- With good caching stratagies, and a very powerful DD, we only spend around 5-10% of our time in the DB. But even with good, parallel front ends, PHP5 spends a lot of time just in the overhead of function calls, which limits how fast a page can load, since we are very deep in function calls.
- +1 - network roundtrips are going to be important now, latency for end user is big thing to focus on
- For us (NetSpot) the main reason this is interesting is to get responses to users much faster - 250ms starts to feel "snappy"
- Edge cases
- Changes of order of precendence in variable function names
- BIggest change and needs to be manually verified
- Changes of order of precendence in variable function names
- foreach changes
- "Most these edge cases are related to manipulation with internal pointer and modification of elements of array, iterated by foreach" [4] These edge cases look really suspicious in the first place and foreach() should be used like that imho --mudrd8mz
- divide by zero is exception, instead of warning
- In the first place, it is a bug in the code so good to have it caught. --mudrd8mz
- E_STRICT is gone
- Need to upgrade code checker rules for PHP 7 support
- Goal is to have all issues fixed for 3.1, an LTS version
- Will be very popular, particularly with large scale installations, so will be keen to get upgrade
- Would need to get plugin developers on board to upgrade their plugins to support PHP7 sooner than later (Travis CI and codechecker warnings are two helpful tools for driving this)
- Question: When is QA site going to be upgraded to PHP7
- Will probably need to run 5.x and 7.x in parallel for a long time
- Yeah, but the QA site, to me, is bleeding edge. Wouldn't it be upgraded to PHP7 first and get some more real world errors.
- Given the perf win, I think we should back-port as many PHP7 fixes to 3.0 and 2.9.
- Disagree - PHP 7 is not out yet and we can't ascertain the full impact of the changes. We may consider it, but I don't think that we should guarantee to do so.
- +1 to focus on 3.1 now, chances for backporting can be only evaluated once we see the actual changes in place. If something, I can imagine functionality blockers to be backported, rather than all warning-throwers. --mudrd8mz
- Alternate take for plugin devs: Big sites have been using your plugin for years for free. This is their chance to give something back. Hopefully they will fix your plugin for you ;-)
- How? 3rdparty is quite a mess to get fixes integrated usually.
- Pull requests in their repositories? --mudrd8mz
- How? 3rdparty is quite a mess to get fixes integrated usually.
Travis CI (Andrew Nicols)
- MDL-51458
- Andrew's setup
- Benefits
- Free to use for open source projects
- Question - what about commercial plugins?
- You can buy Travis, or other CIs.
- Question - what about commercial plugins?
- Help test multiple databases for people submitting patches that don't have different databases installed
- Free to use for open source projects
- Question: We already have jenkins. I don't get the point of this yet.
- Maybe it is for developers that don't have Jenkins setup. Jenkins setup is hours/days, Travis is minutes
- exactly ;)
- MoodleHQ uses it mainly for integration tests only, but idea is to have other people use Travis before it gets to integration stage
- Also, why is this in core, when other dev tools like codechecker are contrib?
- Because you need a .travis file in the root of the casebase to get it to run - its not intrusive, unless you hate dotfiles
- travis.yml
- OK, so it is like .jshint or .composer
- it was not at all clear what Andrew had got integrated.
- Nothing yet, because i reopened it last night :P (Dan)
- Maybe it is for developers that don't have Jenkins setup. Jenkins setup is hours/days, Travis is minutes
- Question: Can you add new tests - e.g. behat?
- You can - but it depends on the .travis.yml file in the root directory (afaik I know)
- There is a time limit of how long tests can run, so there is a limitation on tests that can be run
- Yeah, you'd need to split it up to tiny things
- There's also a fair-use policy and we want to be good Open Source citizens
- Yeah, you'd need to split it up to tiny things
- Question: how does travis know we have pushed?
- Github has a webhook system, and notifies Travis when commits are made (or PRs), you need to set up your account to do this, Travis has docs on that process
- You can configure all sorts of web hooks
- Challenge for someone: githook to submit your trakcer issue for peer review when you push the branch ;-)
- Madman Tim!
- Better one: when someone submits a pull request to moodle/moodle - make it close it and update the tracker issue - thanks i've an issue open for that :D
- Now that is probably something that we can do, but as a webhook unrelated to Travis.
- Github has a webhook system, and notifies Travis when commits are made (or PRs), you need to set up your account to do this, Travis has docs on that process
- Similar tooling for plugin developers: [5] (phpunit, behat, linting etc.for plugins hosted on github)
- [https://tracker.moodle.org/browse/MDL-51458 MDL-51458-master]
- Question: Can we make it work with JoliCi? It fails on Travis-try.
- not a clue - what it JoliCI? Run your TravisCi builds locally
- It's the library to run Travis locally with docker [6] . Unless Travis supplies something else?
- Travis now supports docker
- Oh, nice. Was sure it's only an online service
- I think it is online only, but they document a lot of stuff and there's various 3rd parties that'll try to recreate things locally
- Oh, nice. Was sure it's only an online service
- not a clue - what it JoliCI? Run your TravisCi builds locally
- Comment: Its quite nice how travis integrates into the github UI - you'll start seeing ticks in vrious places
- We probably won't add the ticks - it's more a useful thing for individual developers to help them.
- I think it adds the ticks itself :P I'm sure I saw a cross somewhere on my testing branch! (dreaming probably)
- The ticks yes, but displaying them on the repo - no.
- I think it adds them automatically to Pull Requests, but only if the repo that the PR is going into is set up for Travis
- No it doesn't. It requires you to add a bit of markup to the areas you wish it to be shown. It does *comment* on pull requests, but that's moot since we do not accept them.
- I think it adds the ticks itself :P I'm sure I saw a cross somewhere on my testing branch! (dreaming probably)
- We probably won't add the ticks - it's more a useful thing for individual developers to help them.
Plugin management improvements in 3.0
- Adds support for installing missing dependencies (those listed in $plugin->dependencies that are available in the plugins directory)
- Installing all available updates at once (no need to do one-by-one any more)
- Added support to cancel installation/upgrade of plugins if the DB has not been touched yet
- The previous implementation based on mdeploy.php has been dropped and replaced with a cleaner and unified internal API
- Plugins developers should be well aware of
- The declared $plugin->maturity is taken into account when looking for a plugin version to fulfill a dependency (the most matured, most recent in picked)
- The $plugin->version must be maintained properly so that every plugin ZIP release has unique version number (there is open policy issue to let the plugins directory validate this requirement).
- Plugins database working to have requirement to have different versions for different code releases
Other questions/discussion
- Caching for callbacks (massive decrease in files opened to load every page in Moodle) - use callbacks they are super quick now!
- New drag drop qtypes in 3.0. Yay!
- Yay indeed!
Please feel encouraged to raise topics you would like to present / discuss during these meetings. Contact David Mudrák for details.
