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)
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