Many fixes already made to the migration procedure thanks to a lot of feedbacks
Following the Internet Cube meeting and all the previous discussion, a dedicated âInternet Cubeâ was created on the forum (subcategory of Support) : https://forum.yunohost.org/c/support/internet-cube
c.f. previous discussion and email sent recently on apps@ and contrib@ : started the âmaintenance pingâ thing a few days ago. Maitenance ping issues were created for 40 supposedly inactive apps. For example : https://github.com/abeudin/proftpd_ynh/issues/3
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)
Propose integration into community reposity (c.f. https://yunohost.org/#/packaging_apps , âAsk your application to be added to the app repositoryâ)
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
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 âŚ
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