Currently, only 4 repos come pre-configured with the client: ours, Guardian, and their archives. Of course only ours is activated by default (and I strongly agree to that). But shouldn’t we offer a few more choices to pick from – if necessary with appropriate “warnings”?
Maybe the other way. just having the 4 repos, mark it as under f-droid control. and textview below with “Additional repos - these repos may of may have non-foss stuff” and list then some more repos all being unchecked.
I’d like that. Of course I’d also like to see my repo there () – but other candidates I personally know IMHO include microG. Others might as well.
Because that wouldn’t be very useful. First it would result in a “bloated list”, and second it can be edited by everybody with a forum account. We should have a “curated list” edited by “trusted members”. That group e.g. coud be matched with all members declared “Contributor”, or some “higher state”.
Best might be to have this list in the fdroidclient Git repo, so changes are tracked. Moreover, that’s where the client originates anyway, and only the client needs it. Disadvantage is that changes would only be applied to the next version. And I don’t know if there’s a mechanism similar to fdroidserver’s publishing to wiki.
Open to ideas – for “how to implement” as well as “what should go in”. But “all from this page” is too much and not really useful; some repos contain a single app only, others are out of date or have signature issues. If it’s available from inside the client directly, it should work and be helpful to the user, not “distracting”
That requires a) knowing there is such a list, b) knowing where to find it, c) copy-pasting from browser. Many users will already fail on a+b. But yes, that part would be solved by adding a hint in that place, saying “look there for more”. Still better would be to have some “recommended 3rd party repos”. And I just “forward” what I’ve been asked for multiple times, by the way
You have a point there. I’ve never tried that, but if it works I’d welcome it. Wondering based on what it will be recognized – because the term “fdroid” could be missing from an URL.
I really like this suggestion. It gives enough separation but is still easy to find and use.
For the first cut, it could just open a curated list of repositories in the user’s web browser, or alternatively a webview. The list could live on the official web site so people with commit access to the website have final say.
In later versions, this could become part of the repository itself, allowing repositories to recommend other repositories.
In general, I think it’s a good idea to make more repos visible in the client, but we have to be very careful with two things:
Stating clearly that these repos aren’t under F-Droid’s control and that users add them on their own risk
Don’t bring Replicant at risk which are committed to follow the GNU Free System Distribution Guidelines (FSDG). This means they may only include repos with apps fully free, libre and open source. It seems wowie hasn’t signed up in the forum.
This depends, in my view (ironically) your repo @Izzy would not be allowed as there is no way to update apps once they reach F-Droid and they get removed from yours.
Others like Guardian (they apps), Offi/Briar/Zom (reproducible), @rfc2822 `s Firefox (yes with a warning) might be useful indeed.
You mean my repo wouldn’t be allowed because of signature mismatches? I had expected different reasons (many apps having non-free components).
So why not simply having a single link in the app, saying “click me for more repos”. That pops up a curated page in the browser, listing 100% FOSS repos not pre-configured in the client – and ending with a link to “even more repos”, with a bold red box disclaimer to meet @NicoAlt’s request.
That should fit all. The second page could then even be community editable – or also curated, using issues for RFLs (Request For Listing) to ensure quality. Each entry could have a statement included with our official stanza on it (if any).
Non-free can be removed, a new version without those can be installed just fine, but not when it’s a different signature. You’re basically stuck. And if the app can’t export/import your data it’s a bad experience.
Then maybe that’s the path to follow. In that “second list”, there could e.g. be a warning next to my repo pointing to the signature mismatch (and to non-free components). Similarly, we could annotate other repos there. Which means, that list should probably be curated, too.
) – but other candidates I personally know IMHO include microG. Others might as well.