[Contributors meeting] June 5th, 2018

[Aleks]

Attendees

• Aleks
• Irina
• frju365
• Josue
• ljf
• rouky
• Bram
• Moul

Misc news

• Call for Brique Camp : Brique Camp 2018
• A few apps downgraded to inprogress / notworking : Notworking apps by maniackcrudelis · Pull Request #506 · YunoHost/apps · GitHub
• Improvements in Tartiflette / dash : https://dash.yunohost.org/ (filters, and the ‘Apps observatory’)
• Some apps are now flagged as “unmaintained”, c.f. previous discussions, Update maintained state by alexAubin · Pull Request #522 · YunoHost/apps · GitHub and Handle 'unmaintained' state on app page by alexAubin · Pull Request #732 · YunoHost/doc · GitHub
• Issues got migrated to Issues · YunoHost/issues · GitHub
• annnnnd Microsoft bought GitHub A bright future for GitHub - The GitHub Blog
• Work on services by Bram (especially UX improvement regarding services descriptions)
• POC for app actions [enh] POC for app actions by Psycojoker · Pull Request #486 · YunoHost/yunohost · GitHub

Discussion with rouky / feedback from his user point of view

• UX regarding managing the backup of application’s data

PR to discuss / review

Log/Journals PR

• journals/operational logs by Psycojoker · Pull Request #165 · YunoHost/yunohost · GitHub
• Web interface for journal new features by Psycojoker · Pull Request #130 · YunoHost/yunohost-admin · GitHub
• [fix] Display the date in a correct format by zamentur · Pull Request #163 · YunoHost/moulinette · GitHub
• (General discussion around this PR)

ynh_info / verbose by default

• [enh] Add ynh_info helper for app scripts by alexAubin · Pull Request #383 · YunoHost/yunohost · GitHub
• [enh] Optionnal stdinfo communication channel when running commands by alexAubin · Pull Request #155 · YunoHost/moulinette · GitHub
• [enh] Verbose by default by alexAubin · Pull Request #487 · YunoHost/yunohost · GitHub

Towards a stable release for Stretch

Goal : release as stable around June 15th

Todo :

• moar tests - if you are in dev team and have instances, please run the migration to gather feedback
• run dem unit tests Bram: all pass \o/
• set stretch-unstable as the default branch for PRs
• please check your apps that appears on https://dash.yunohost.org/appci/compare/stable...stretch
• prepare an update of the doc
• prepare announcements
• Postgresql migration ? (Stable ?) https://github.com/YunoHost/yunohost/blob/stretch/src/yunohost/data_migrations/0005_postgresql_9p4_to_9p6.py#L28-L32
  • email thing, try to see if we can find a debconf option: apt install debconf-utils; debconf-get-selections | grep postgresql
  • implement the todo to check for free space
  • add some sanity check that tables were correctly migrated before/after the pg_upgradecluster before deleting the 9.4 cluster
• Build new images

[Github] Abandon ship

wat do nao

Available options:

1. Stay on Github forever
2. Stay on Github until there’s a federated git network ?
3. Move to a “friendly” instance like Framagit
4. Move to a big “company” instance like gitlab.com
5. Self-host an instance

Overall the consensus seems to be around option 3

(gitlab.com looks too much like the new github owned by a private corp, and self-hosting is quite a lot of work, c.f. the experience we had with redmine)

(Bram and ??? already registered Yunohost and YunoHost-apps on framagit)
(Rafi did some tests / moved his apps on framagit ?)

Pieces with hard-coded Github stuff right now :

• app.py
• app list builder
• the issue tracker
• simone for automatic PR submission
• tartiflette / dash
• weblate / yunohost-bot PRs
• the general pull request process
• vinaigrette / the deb build chain
• maybe pieces in the app CI or package check / linter
• ???

[Organization] Being a sustainable project

Making YunoHost a sustainable project

About one year ago, we were giving a talk with ljf at PSES about YunoHost. At the end of the talk, one question that got asked was along the lines of : « It is now recognized that YunoHost is an important project for Internet’s decentralization. What is YunoHost’s model to make it a sustainable project ? ». At that time, my reaction was to see someone telling us that YunoHost needed money to be a serious project. And I was pretty much convinced that we didn’t have to. My position was that …

Communication about donations / Liberapay :

• on the forum
• in ssowat / the webadmin
• on the website
• communication strategy (e.g. which websites to communicate on, each time we have a release / an announcement)

We need somebody (and/or together) to start communicating about the project

Possibilities to gather money:

• subventions / public funding
  • Tango & scan 2019
  • RIPE
  • EU / Next-generation internet
• crowdfunding
• donations
• SaSS ?
• plug and play backup
• consulting on the core (but we need to find people that would be interested for that)
• contact big associations
• hosting provider (like gandi)
• professionnal support
• formation ?

We kinda conclude that we should at least setup an association and start looking deeper / implementing some of those.

TODO:

• contact kload to know if we cant recycle the old association ? (Done : we cant)
• highlight / communicate ways to donate to the project
• establish a preliminary budget ? with “steps” ?
• subscribe to crowdfunding platforms ?

Idea of a separate wiki for Apps Documentation

Discussion around how to organize the documentation for apps. This is related to the few pages like YunoHost • index which arent really exploited, and about the README in the apps repo which arent displayed to people legitimately not knowing about app’s repo - yet sometimes repos contains important info.

One possibility could be to have the doc pages hosted inside each app’s repo, inside a doc/ folder (in addition to the readme). This could then be imported in the general doc, and/or accessible from the webadmin.

README.MD
doc/
   USER.MD
   CONTRIB.MD

TODO : create an issue to talk about this

Next meeting

June 19th