[Contributors meeting] May 15th, 2018

Contribute Room
2

Attendees

  • Aleks
  • Gofannon
  • Maniack
  • Josue
  • ljf

Misc news

[Apps helpers] Discussions about two new helpers

ynh_maintenance_mode

ynh_handle_getopts_args

[App packaging] Questions and discussions with Gofannon and his experience with app packaging as a newcomer

  • Which apps should be done in priority?
    • => Is there some information somewhere ? (Nothing here https://yunohost.org/#/packaging_apps )
    • Work on application used by maintainers : better implication + testing
    • There’s no official list of things to do in priority
  • Is there an “easy” list to contribute to ?
    • nop, take an offcial app and check the issues on github. If they can be solved
  • How do we know someone is already working on an app ? In order to avoid doing the work multiple times ? Is there a dashboard ?
    • Check on github for a application_ynh repo and ask to the maintainers
    • No easy way of doing this. I guess that developpers are used to git to manage conflict if something happens instead of non dev people (I had a discussion about git and the personn explined that to me that it was easier to manage “conflict” when they happen rather than assign the work beforehand)
  • I work on the app https://github.com/Gofannon/cheky_ynh/tree/testing, how to ask for help with it ? Ask on the forum for advices ? Do a PR to the official app ?

We also discussed a specific issue related to checky, which is the new maintained fork(?) of LCBAlerte and some sort of migration should be implemented. This is pretty similar to the owncloud->nextcloud migration. Maniack created an helper a while ago to make these kind of migrations easier.

[App packaging] Extending app manifests to specify ressources (typically RAM) consumed by an app

For instance :

"requirements":{
    "yunohost": ">x.y.z",
    "ressources": {
         "RAM": "1GB" 
    }
}

This would be in particular useful for apps which are known to require significant ressources (e.g. synapse, sympa, …). We could already start adding these to app’s manifests even though it’s not used yet …

[Core] Backup vs. regen-conf

Discussion started by discussing this https://github.com/YunoHost/yunohost/pull/442

  • Basically, sometimes we backup/restore some files which might be modified in the future, hence the backups are not future-proof.
  • We should rely as much as possible on the regen-conf mechanism instead of brutally restoring raw files. But there’s the question of handling files known to be manually-edited by users…
  • Currently some things like dyndns domains are not properly restored because not managed by the regenconf…

Todo :

  • properly handle the dyndns thing in backup/restore (currently keys are not backuped)
  • we shouldnt restore files that werent modified (according to the regenconf) on the initial setup
  • it doesn’t make sense to be able to do partial-restore (only ldap, only nginx, only mysql, …) so we should merge all these in a single ‘conf’ backup/restore hook.
  • (not related but) remove all traces of archivemount as it’s causing weird UX stuff and isnt really useful
  • backup /etc
  • backup list of dpkg packages
  • maybe keep track of files changes compared to debian default

Next meeting

June 5th