Actions

Developer Area/Developer Meetings/72: Difference between revisions

From Mahara Wiki

< Developer Area‎ | Developer Meetings
No edit summary
No edit summary
 
Line 7: Line 7:


* Chair: Gregor Anzelj
* Chair: Gregor Anzelj
* Minute taker: Rebecca Blundell
* Minute taker: Kristina Hoeppner




Line 31: Line 31:
<li>Next meeting and chair</li>
<li>Next meeting and chair</li>
<li>Any other business</li>
<li>Any other business</li>
= Attendees =
* Gregor Anželj, POVSOD, Slovenia (chair)
* Kristina Hoeppner, Catalyst IT, Wellington, New Zealand (note taker)
* Robert Lyon, Catalyst IT, Wellington, New Zealand
* Tobias Zeuch, Karlsruhe, Germany
= Items from last meeting =
* Gregor
** to test if language strings that exist in both 19.04 and 18.10, for example, are both translated if he only changes it in 19.04: Yes. If you change a string in one language, it's updated in another on Launchpad. This is OK because when strings change meaning, we are creating a new one.
** to contact Synergy about the test timeline of the access moderation: In progress. Gregor still needs to make some changes and pull latest master for that.
** to create bug report around the issue he encountered exporting users from one instance and importing them into another: Not done yet -> put on agenda for next time
* Robert to look at https://reviews.mahara.org/9634 and see what is needed to correct the issue as it may be a fundamental one: Still in progress.
** Normally, when doing an export and import, all artefacts are owned by the new user. But peer assessments are owned by someone else, which is tricky to handle because that person may not exist on the other site.
** What happens when you import data from another site where someone else has assessed you and how to link that up?
** Peer assessment is not owned by someone else but by the user who's importing, but then you can't really peer assess yourself.
** '''Idea''': Import the block as static content because the user may not be present.
** '''Idea''': Extra information that this was imported from another site and thus not a peer assessment from the current site.
** '''Note''' for future: When exporting data, we also need to think about how to re-import it.
* Peter to to submit the changes for core changes to support sending of Mahara notifications to Moodle: Not done yet.
* Kristina to create forum post on the dev meeting format to see what those that didn't attend think: [https://mahara.org/interaction/forum/topic.php?id=8452 Done on 12 May 2019.]
** Only one response on the forum post.
** Follow-up post about audio / video recordings. Note that if audio / video is done, it needs to be clear to participants so they can decide whether to participate.
* Cecilia to make forum post outlining an interim mitigation for the trigger issue: [https://mahara.org/interaction/forum/topic.php?id=8450&post=33705 Done on 3 May 2019].
** This is a mitigation.
** We are still looking into removing triggers for 19.10, and Robert is working on that.
=Support for new and old versions of PHP, Postgres, MySQL=
* Versions of PHP in particular are moving along very quickly, and right now it is not always very clear to the community which versions we are supporting, and which ones we are not supporting anymore or just yet.
* We update libraries on a regular basis, but support for PHP, Postres, MySQL is a bit fuzzy and might be good to make it more explicit about what we support.
* MariaDB is not officially supported, but later versions should work for the most part. We are not doing much testing on MariaDB at this stage.
* '''Important''': Be transparent about what versions are supported, e.g. in the Readme for each version and on the wiki installation page. That includes giving the upper limit and not just the lowest version.
* Often we don't use new features of PHP or databases and thus older versions can often be used.
* Also need to ensure that Mahara supports newer versions of PHP. E.g. PHP is moving quite quickly and thus we should be supported within our 18-month support cycle of Mahara. We can't ensure that for every single PHP version though if there were major jumps. Sometimes people may need to upgrade Mahara.
* '''Idea''': Set up some Docker images that have newer versions.
* '''Idea''': Look into newer versions of PHP earlier than we've done in the past to check what's changing and how that affects Mahara.
* New databases introduce better ways for searching rather than change SQL entirely. Will need to be looked into with Mahara sites growing and thus performance becoming increasingly important.
* Reflect on this a bit more and gather feedback from other developers.
= Next meeting =
* [https://www.timeanddate.com/worldclock/fixedtime.html?iso=20190731T07&p1=1440 31 July 2019, 7:00 UTC]
* Chair: Robert Lyon
* Minute taker: Cecilia Vela Gurovic
= Any other business =
* Tobias' summer project '''idea''': Set up docker images to test plugins, e.g. the calendar plugin for plans. There is one [https://hub.docker.com/r/mhughes2k/mahara Docker image] that was posted about on [https://twitter.com/mhughes2k/status/1140908974461599744 Twitter] recently.
* Catalyst New Zealand team has some virtual machines (not Docker-based) in the cloud for testing purposes that require a bit of love to make them fully functional. The idea was to make it possible for testers to  plug a code review number in, the code is pulled, and they have a Mahara instance with the code available as well as a database to perform their testing. We are in the beginning stages of this work flow and still need a bit to make it fully functional.
= Actions =
* '''Gregor''' to create bug report around the issue he encountered exporting users from one instance and importing them into another
* '''Peter''' to submit the changes for core changes to support sending of Mahara notifications to Moodle.
* '''Kristina''' to follow up dev meeting forum post about audio / video recordings. [https://mahara.org/interaction/forum/topic.php?id=8452 Done on 30 June 2019]
* '''Robert''' to post about PHP and database version discussion in the developer forum to engage other developers who were not present in the meeting.

Latest revision as of 19:27, 30 Haziran 2019

Agenda for the 72nd Mahara developer meeting on Wednesday, 26 June 2019, 7:00 UTC

We will meet using Meet.Catalyst (a Catalyst staff member will initiate the call).

Our #mahara-dev channel on Freenode IRC will be our backup or in case there are problems with the web conferencing tool and we'll need to chat to resolve it. If you don't have an IRC client, you can join us using your web browser.


  • Chair: Gregor Anzelj
  • Minute taker: Kristina Hoeppner


Agenda

  1. Items from last meeting
    • Gregor
      • to test if language strings that exist in both 19.04 and 18.10, for example, are both translated if he only changes it in 19.04.
      • to contact Synergy about the test timeline of the access moderation.
      • to create bug report around the issue he encountered exporting users from one instance and importing them into another
    • Robert to look at https://reviews.mahara.org/9634 and see what is needed to correct the issue as it may be a fundamental one.
    • Peter to submit the changes for core changes to support sending of Mahara notifications to Moodle.
    • Done:
      • Kristina to create forum post on the dev meeting format to see what those that didn't attend think. Done on 12 May 2019.
      • Cecilia to make forum post outlining an interim mitigation for the trigger issue. Done on 3 May 2019
  2. Support for new and old versions of PHP, Postgres, MySQL (Discussion start: Kristina)
  3. Next meeting and chair
  4. Any other business
  5. Attendees

    • Gregor Anželj, POVSOD, Slovenia (chair)
    • Kristina Hoeppner, Catalyst IT, Wellington, New Zealand (note taker)
    • Robert Lyon, Catalyst IT, Wellington, New Zealand
    • Tobias Zeuch, Karlsruhe, Germany

    Items from last meeting

    • Gregor
      • to test if language strings that exist in both 19.04 and 18.10, for example, are both translated if he only changes it in 19.04: Yes. If you change a string in one language, it's updated in another on Launchpad. This is OK because when strings change meaning, we are creating a new one.
      • to contact Synergy about the test timeline of the access moderation: In progress. Gregor still needs to make some changes and pull latest master for that.
      • to create bug report around the issue he encountered exporting users from one instance and importing them into another: Not done yet -> put on agenda for next time
    • Robert to look at https://reviews.mahara.org/9634 and see what is needed to correct the issue as it may be a fundamental one: Still in progress.
      • Normally, when doing an export and import, all artefacts are owned by the new user. But peer assessments are owned by someone else, which is tricky to handle because that person may not exist on the other site.
      • What happens when you import data from another site where someone else has assessed you and how to link that up?
      • Peer assessment is not owned by someone else but by the user who's importing, but then you can't really peer assess yourself.
      • Idea: Import the block as static content because the user may not be present.
      • Idea: Extra information that this was imported from another site and thus not a peer assessment from the current site.
      • Note for future: When exporting data, we also need to think about how to re-import it.
    • Peter to to submit the changes for core changes to support sending of Mahara notifications to Moodle: Not done yet.
    • Kristina to create forum post on the dev meeting format to see what those that didn't attend think: Done on 12 May 2019.
      • Only one response on the forum post.
      • Follow-up post about audio / video recordings. Note that if audio / video is done, it needs to be clear to participants so they can decide whether to participate.
    • Cecilia to make forum post outlining an interim mitigation for the trigger issue: Done on 3 May 2019.
      • This is a mitigation.
      • We are still looking into removing triggers for 19.10, and Robert is working on that.

    Support for new and old versions of PHP, Postgres, MySQL

    • Versions of PHP in particular are moving along very quickly, and right now it is not always very clear to the community which versions we are supporting, and which ones we are not supporting anymore or just yet.
    • We update libraries on a regular basis, but support for PHP, Postres, MySQL is a bit fuzzy and might be good to make it more explicit about what we support.
    • MariaDB is not officially supported, but later versions should work for the most part. We are not doing much testing on MariaDB at this stage.
    • Important: Be transparent about what versions are supported, e.g. in the Readme for each version and on the wiki installation page. That includes giving the upper limit and not just the lowest version.
    • Often we don't use new features of PHP or databases and thus older versions can often be used.
    • Also need to ensure that Mahara supports newer versions of PHP. E.g. PHP is moving quite quickly and thus we should be supported within our 18-month support cycle of Mahara. We can't ensure that for every single PHP version though if there were major jumps. Sometimes people may need to upgrade Mahara.
    • Idea: Set up some Docker images that have newer versions.
    • Idea: Look into newer versions of PHP earlier than we've done in the past to check what's changing and how that affects Mahara.
    • New databases introduce better ways for searching rather than change SQL entirely. Will need to be looked into with Mahara sites growing and thus performance becoming increasingly important.
    • Reflect on this a bit more and gather feedback from other developers.

    Next meeting

    Any other business

    • Tobias' summer project idea: Set up docker images to test plugins, e.g. the calendar plugin for plans. There is one Docker image that was posted about on Twitter recently.
    • Catalyst New Zealand team has some virtual machines (not Docker-based) in the cloud for testing purposes that require a bit of love to make them fully functional. The idea was to make it possible for testers to plug a code review number in, the code is pulled, and they have a Mahara instance with the code available as well as a database to perform their testing. We are in the beginning stages of this work flow and still need a bit to make it fully functional.

    Actions

    • Gregor to create bug report around the issue he encountered exporting users from one instance and importing them into another
    • Peter to submit the changes for core changes to support sending of Mahara notifications to Moodle.
    • Kristina to follow up dev meeting forum post about audio / video recordings. Done on 30 June 2019
    • Robert to post about PHP and database version discussion in the developer forum to engage other developers who were not present in the meeting.