I (sysadmin some patching) don’t have an exact idea or picture, yet.
That’s also a reason why aspects like sharing things, release upstreaming ideas, roadmap complements, etc. may still be confusing.
It may all boil down to contemplate for some period of time if yunohost and freedombox developers would be open to find and pursue collaboration.
Finding a way usually only comes about by looking at things from many different angles and approches, though. Until a picture or structure starts to develop, over time, that is promising enough to pursue.
(A funny thing is that it’s currently not even clear where upstream nor downstream would be exactly. Debian and the freedombox package maintainers may be upstream for yunohost but at the same time the yunohost package repository would be upstream for a freedombox.)
I liked your (technical) responses. Let me add some of my thoughts.
point is, you don’t know in advance what are going to be the changes in future debian release, and because everything in a server distribution is pretty tight-coupled, it’s very hard to make anything “future proof”.
I think instead of trying to foresee all changes and “future-proof” things, the approach to this would be to have things in debian sid and see (get a list of errors and reports) as soon as something breaks. Allowing to see if it’s something one has to deal with sooner or later, or if it’s something that can or has to get fixed by or with others. (Freezing and stabilizing together with the next release.)
root issue for slowness of moving to the newest Debian release is : number of humans actually working on it. […] we need people to actually put their hands in the dirt and run tests and implement fixes and ask questions and just make it work.
I think part of the solution is that every yunohost bit that gets into Debian sid/testing gets much more accessible (servers around the world) and broader exposure. And if collaboration can be agreed on with the goal that the freedombox “stable” users get a way to install major ynh packages like nextcloud, it will even find the way to people in another self-hosting community with interest to test and fix packages.
I was about to say something about how it would be nice to have something like a standard, default, abstract specification that web app could implement (independnetly of yunohost)
Well, that’s part of what I like so much about yunohost. You actually stepped up and made concrete specifiactions that allow to conveniently install webapps. Now, a basic solution exists, for others to pick it up, and join the efforts, but it can likely only happen if you want that, and pursue it for a start.
Even if it’s just for debian+common-helper-package based systems, I’d expect web-apps for debian to likely have a surprising range.
Personally, I think in your shoes I would try to see if there are other devs with overlapping interests in bootstrapping this. (Like freedombox developers especially, with such closely matching things on their roadmap.)
As the common basis is Debian, not Arch, Alpine etc., and thus there are already many useful rules on how packages relate etc., I don’t think starting collaboration and merging/upstreaming some parts would be out of this world.
Please also don’t expect the following to be anything that’s already exact, but here are some more concrete thoughts to contemplate and consult about, if yunohost wants to reach into a larger developer base.
- If collaboration is first only pursued for the web-app packaging specification and helpers, the two web server stacks may not neccessarily have to be made installable on the same machine.
- Can the ynh and fbx web frontends both access two separate backends (for specific disjunct areas) allowing for consolidation over time? (Freedombox does have a backend/frontend separation.)
- To be realistic, upstreaming some things will likely also mean to coordinate to step back on something and adding what’s needed to the other’s something. (See this as a crucial step to lower and focus the workload.)
For example, to be willing to migrate to another LDAP schema, in order to be able to gain more users and developer exposure and collaboration for ynh_* helper features etc.
- I don’t think the yunohost project or community would be reduced, even if all the infrastructure would be part of debian proper (the community may rather enlarge), because I don’t see all the web-apps to become part of the debian releases. So it’s always needed to keep up with all the web-app developments, if yu-no-host…, even if the same infrastructure is also used and maintained by others to set up and administer pure debian servers with web- and .deb packages around the world.
Maybe we should take it a little slower, and first look around for possibilities some more. But if yunohost devs are interested to increase the reach, maybe some exchange with freedombox devs can bring out the most fruitful ideas. (Not quite “putting hands in the dirt” yet, but a start still.)
Looking forward even if devs can respond to this only after some days or weeks.