Dear YunoHost contributors,
we will have our next meeting on Tuesday, May 1st, 2018 
. It will be on the usual Mumble server (kload.fr:64738) at 20h30 UTC+2 !
NB: You are welcome to join even if you’re not currently contributing and/or just want to discover and see how things works in the project. 
Here is the pad’s link where you can prepare the meeting:
https://pad.lqdn.fr/p/yunohost-01-05-2018
Feel free to add topics and bullet points you would like to be discussed during the meeting !
Many fixes done on the stretch-migration and stretch branches (especially the infamous disappearance of the ‘installed’ flag)
There’s also a new migration for postgresql 9.4 -> 9.6 db migration which is still kinda yolo at the moment (here)
Redeployed the deb buildchain on forge.yunohost.org which is to be the final one (‘forge2’ lxc is a yunohost stretch instance)
Gotta discuss how to handle the beta release
TODO Alex : disable https for forge nginx conf (causing stuff with apt-transport-https)(no worries, deb are checked with GPG)
TODO Alex : recheck migration with nextcloud
TODO Alex : recheck ISO thing, might be due to the https thing
TODO Alex : remove the http2 thing for now as it’s causing issues 
In the end, we decide to open the beta on unstable, maybe move it to testing after we release the stable in a few days (c.f. next point)
c.f. https://github.com/YunoHost/yunohost/compare/stable...unstable
Regarding the CSP config, we decide to keep the “upgrade-insecure-request”, but to move the other stuff to a -Report-Only header (“debug mode” of the CSP) until we have a better understanding of what we should do with this.
Regarding the release, we decide to go for a testing release for ~3 days to catch up with the CI, then release a stable if there’s no show stopper.
add_headers in nginx conf (Related to previous CSP item)‘Funny’ thing, kinda related : https://blog.g3rt.nl/nginx-add_header-pitfall.html
(tl;dr : if you put any add_header in a nginx conf bloc, it forgets about every previous add_header in the parents…)
One solution is to use more_set_headers instead (already available via nginx-extras) …
We could add a check in the app linter that add_header isn’t used … if it is, then advise to use more_set_headers instead…
Follow-up of some previous discussions about “how do we check that an app is actively maintained”
Proposal is to basically create a “maintenance ping” issue on app repo if no activity on master or testing happened for a given period of time. If no answer is given after for example 2 weeks, the app is flagged as “unmaintained”.
Proof of concept started here : https://github.com/YunoHost/tartiflette/tree/master/app/scripts/maintenancePing
If we set the limit to 18 months of inactivity (=~ 550 days), we get this list of 41 apps for which a maintenance ping should be created : https://paste.yunohost.org/raw/kabojewosi
TODO : send a mail to the app groups when such ‘maintenance pings’ are created
TODO : run this ! (someday when there’s time)
May 15th
