I have installed and tested etesync on my openwrt router. I want to share the packages for etesync and its dependencies that are not in the official feed. But I am new in contributing. Do you have mentors or so? Right now I have the following questions:
How should I publish the packages: All of them as one pull request or separately?
The README.md of https://github.com/etesync/server-skeleton suggest to install it via virtualenv. But I made packages for the (missing) dependencies, too. Would it be advisable to use a virtualenv instead?
Is there a how to make a package uci compatible?
Could anybody look over my changes and give me feedback?
Thank you for your answer, I made the following topic branches:
The latter one is for moving the luci on nginx related files from the nginx and the uwsgi-cgi package to the luci-nginx and luci-ssl-nginx package. I would make this change only if @Ansuel approves it since it is his project.
This is a first proposal and there are some points still missing:
Install etesync to another folder (instead of /etesync-server). What would be the canonical place?
Maybe add uci support and a luci app for etesync, mainly for configuring the server name; there is already a admin interface build in for user management.
Create a self-signed certificate and enable ssl in the etesync server section of the nginx configuration.
I am not sure how to interact with the nginx configuration. Do you have any suggestions? Would it help to make it available via uci? Or would that be a bad idea or difficult?
Etesync starts a uwsgi instance; how can I restart it after an update of uwsgi? Would that be a good idea at all?
I put a lot of changes into one commit, would it be better to split it up? If so, how fine, every dependent package one commit? I would do that in another branch of peter-stadler/packages.
@Ansuel: Do you think, I should make a PR already? I would at least complete points 3 (ssl certificate) and 6 (autostart), and do some work on point 7 (conf files) before.
At least at this point, the questions seem to be ones that "developers" can answer. At least as I understand it, the "Community Builds..." section is for content that end-users can download and install (without building it themselves) and for support of such content.
I adopted the PRs for nginx (as well as ariang) and the modular uwsgi to follow the recent changes. Furthermore, I did split up the django2 PR into single packages:sqlparse, django-cors-headers and drf-nested-routers. These PRs are quite ready imho and I removed the draft status.
I will make another PR for the django-etesync-journal as it is missing for now. Then I will change the PR for the etesync-server, too. And I am not sure wether we should integrate the luci mods into the uwsgi and nginx Makefiles or if we could collect them; in the second case I would update the luci PR.
We need to hear the devs opinion... As i already said... hen i first tried to push luci on nginx they told me that a different package can't modify files of others... For this specific reason i had to create 2 subpackage for nginx and uwsgi... Anyway i will update nginx to mainline version so i think we can merge your changes before my commit. What do you think? Also can you put the pr in a list so i ca check them quickly?
I see, maybe it is different when we use the subfolders (/etc/nginx/conf.d and /etc/uwsgi/vassals) since the purpose of these folders is for other packages to install their files there.
If the conf.d folder can be enabled, the nginx PR could be merged anytime.
I did link all the current PRs in my last post, the first six would be ready: