Workflow for Managing Remote Storage
This is the main ticket for dealing with remote storage. Please feel free to create corresponding sub-tickets as required.
Types of Remote Storage
We currently support these types of remote storage, but more might be added later on.
- Default Storage
- Needs to be set up be a system administrator of an web-instance
- Users can not change it
- Maybe we want to give users the ability to disable default storage (future feature)
- Amazon S3 Storage
- Can be set up by users
- Always uses the same form
- Might require additional instructions
- SSH Server Storage
- Can be set up by users
- Always uses the same form
- Needs SSH key (automatically generated in multi-user mode)
- Might require additional instructions
- Git Storage
- Can be set up by users
- Always uses the same form
- Needs SSH key (automatically generated in multi-user mode)
- Has currently simple instructions for using GitLab
Instructions
The default storage should work out of the box and doesn't require any instructions.
All user-configurable remote storage options might require instructions to guide the user through the setup process.
Remote storage that requires an SSH key (currently SSH and Git) even requires a setup step after the remote storage has been added by the user. This is because the SSH key is generated when the storage is added and then it still needs to be added by the user to their SSH Server or Git Service Provider.
Because of this, we might want to add these kind of storages as disabled and only enable them when the user has informed us that she added the SSH key shown to her.
Error Handling
Remote storage might fail for many reasons, temporarily or permanently, initially or only later on. We probably want to disable remote storage that failed too many times.
Whenever something in the repository is changed, it is published automatically to all configured and active remote storage providers.
Use-Cases
- Adding a new remote storage
- Modifying an existing remote storage
- Noticing a remote storage is not working properly (anymore)
- Re-enabling/re-trying an existing remote storage after it has been disabled due to too many errors
- Maybe also manually disabling, but not deleting a remote storage
- Removing a remote storage, maybe with the option to delete the repository from it, to not leave outdated repos behind
Activity
changed milestone to %1.0
mentioned in merge request !62 (closed)
mentioned in merge request !69 (merged)
added Doing and removed ~2112488 labels
The default storage should work out of the box and doesn't require any instructions.
Default storage will only be set up if a system admin sets it up, correct? Meaning, F-Droid isn't providing a default storage location.
Thank you @grote. Here's an initial design that is pretty close for setting up storage when none exists. (The options section still needs some love.)
This design was created with a couple things in mind.
- Users can quickly get overwhelmed by choice, especially if they don't have a knowledge base for making a decision.
- At least half of our target audience will not be technically savvy enough to know what SSH is and most likely won't have any kind of storage options easily at hand.
The idea is to 'make the choice for them' by presenting the easiest option and simple instructions.
As a side note, for the more tech savvy users (ie developers) that log in to Repomaker with Github, we could offer Github for their storage as the default.
Here's an initial design that is pretty close for setting up storage when none exists.
Thanks! Looks very nice as usual!
At least half of our target audience will not be technically savvy enough to know what SSH is and most likely won't have any kind of storage options easily at hand.
I think you are right. I'd still offer it as an option though. The people who could use it, will know what it is when they see it.
To explain a little more: SSH is just a technology that can be used to copy files securely to remote computers. When using Git as storage, the files will also be copied via SSH. But the pure SSH option directly copies the files without using any other technology.
The idea is to 'make the choice for them' by presenting the easiest option and simple instructions.
That makes total sense. I am just not sure promoting certain companies so prominently.
Git as well as SSH are vendor neutral technologies that have Free Software implementations and can be used by anybody who knows how to set them up. GitHub and Gitlab are two different companies that offer free hosting of Git repositories and as such they are the easiest storage option we offer indeed (with the exception of the default storage).
As a side note, for the more tech savvy users (ie developers) that log in to Repomaker with Github, we could offer Github for their storage as the default.
I think that would be great (same goes for GitLab), but I would consider it a new feature. There we could also make the repo setup almost automatic (if we had the time for it...).
When developing the designs for this workflow further, please also consider that we currently have the concept of a primary storage (you can see the checkbox when adding a storage on the test server). Technically, a repo needs to have an address (URL) where users can reach it. Each storage produces such an address. The address used for the repo is the address of the primary storage.
@crwinfrey I agree to Torsten, the design looks great! Thank you.
To add to Torsten's comment on promoting GitLab/GitHub: I also have concerns about this. Maybe we can change the text to not promote GitHub and GitLab but Git. Then we can say something like "Store it with Git". The further description could be something like "Git is a popular tool to version control things. You can use it to publish repos on GitLab, GitHub or any other Git service.".
Like Torsten I think that we should offer all options. With Git at the top, we could show Amazon S3, SSH, and other storages in future.
I think you are right. I'd still offer it as an option though. The people who could use it, will know what it is when they see it.
I agree. The options are still shown in the mockup. Did you see that?
To explain a little more: SSH is just a technology that can be used to copy files securely to remote computers. When using Git as storage, the files will also be copied via SSH. But the pure SSH option directly copies the files without using any other technology.
Thank you for that. :) You're explanation is way better than wikipedia.
That makes total sense. I am just not sure promoting certain companies so prominently.
Got it. I'll re-think the design so that we're not promoting a company so much.
When developing the designs for this workflow further, please also consider that we currently have the concept of a primary storage (you can see the checkbox when adding a storage on the test server).
If a user check this, does it automatically add the primary storage to each repo created thereafter?
To add to Torsten's comment on promoting GitLab/GitHub: I also have concerns about this. Maybe we can change the text to not promote GitHub and GitLab but Git. Then we can say something like "Store it with Git". The further description could be something like "Git is a popular tool to version control things. You can use it to publish repos on GitLab, GitHub or any other Git service.".
I do like this option. :) Thank you both for the feedback!
-
@crwinfrey Again, thank you for the feedback :)
If a user check this, does it automatically add the primary storage to each repo created thereafter?
Nope, this just affects the current repo. It mainly means that the URL of the primary repo is used as the main URL of the repo, e.g. "view repo", "share public link", etc..
Nope, this just affects the current repo. It mainly means that the URL of the primary repo is used as the main URL of the repo, e.g. "view repo", "share public link", etc..
Ok. Right now in the UI, the description we provide for this option is "Make this storage the primary storage of the repository." Currently, this doesn't help me understand what actually happens if I check it. I don't want to belabor this because I know we're trying to wrap up, but, so that I understand— What happens if a user doesn't check this box? It the URL path something different? @NicoAlt @grote
Also, I'm working on this mockup now.. To use SSH, does a user have to have their own web server set up already? I realize this makes sense to advanced users. I'm just trying to break down the options to provide enough info to help users decide which to use. Thanks!!
-
I don't want to belabor this because I know we're trying to wrap up
Absolutely no problem, ask everything what's unclear to you!
Right now in the UI, the description we provide for this option is "Make this storage the primary storage of the repository." Currently, this doesn't help me understand what actually happens if I check it. What happens if a user doesn't check this box? It the URL path something different?
OK, I checked this locally again. Every repo has to have one primary storage. That means if you just have one, that's your primary. If you have no storage and add one, that's automatically your primary one.
On repomaker.grobox.de Torsten added a default storage. This means, every repo that is created on repomaker.grobox.de is published to this storage. Until the user adds another storage, this default one is also the primary one.
If you have more than one storage, you can choose which one of them is the "primary storage". Every storage that is not the "primary storage" is just a mirror.
"Primary storage" has effects to the following points:
- The URLs in repo share view (view repo, copy link, scan qr) will be the URL of the primary storage
- The F-Droid client will download the index and everything related from the URL of the primary storage
To use SSH, does a user have to have their own web server set up already?
Yes, they need some sort of web server for SSH.
I realize this makes sense to advanced users.
Sometimes there are also hosters which offer the possibility to upload via SSH. So this can be interesting for less-experienced persons too.
do we need to say that they can use any other Git service?
Yes, I would do this. You're right, GitLab and GitHub are the most popular but there are many other services and our target group might not trust GitLab or GitHub as they are both hosted in the US.
-
Great work, @crwinfrey! Thank you that you addresses all the feedback provided by us. Because this is a huge but important step I'll immediately start implementing it.
I only think you mixed up some "Info"s and "Share"s. The first header should be "Share" and the second and fourth "Info", but I think I know what you mean.
Do you thought about the detail view you get to when clicking on a storage? This only works with non-default storages, though, what could be the reason you never went there:
mentioned in issue #144 (closed)
mentioned in issue #145
-
Do you thought about the detail view you get to when clicking on a storage?
I restyled it a bit as part of !126 (merged):
I think we are fine with this issue then, thank you for all!
mentioned in issue #146 (closed)
I only think you mixed up some "Info"s and "Share"s. The first header should be "Share" and the second and fourth "Info", but I think I know what you mean.
@NicoAlt Oh, yes. Sorry about that. You're right. I moved the images around and forgot to update the titles.
Do you thought about the detail view you get to when clicking on a storage? This only works with non-default storages, though, what could be the reason you never went there:
Yeah, I didn't see that view. The restyling you did looks good! I would tweak a few things:
- change the link colors to the blue we're using in the app and
- style the green 'enable' button to match our solid blue filled
- style the gray buttons to match our dark gray outline style
- use the cloud image I've attached rather than the material design icon :)
removed Doing label
