Not sure what it shows, sad to see everyone talk about this like it’s F-Droid’s fault when: a closed source network service treats its users as hostiles changing APIs willy-nilly breaking 3-rd party apps.
Read that phrase again, and again, and again, and stop ranting about what F-Droid can do or doesn’t do.
Did the F-Droid build service break? No.
Did the F-Droid publishing service break? No.
Did the F-Droid APK download service break? No.
Did the F-Droid app submission break? No
Does the site at fault still work in a browser? Yes, USE THAT! PANIC END.
/PS: Merge requests to streamline the F-Droid workflow are welcomed here:
Let’s fight this people, let’s fix it! git clone !!!
Exactly, how many of these who are “affected” (allow me to roll eyes here) would start contributing to F-Droid? I guess rather none. Once the fixed version is in everybody continues with their lives, the next day it was all a dream. (Until next time, there’s always a next time when it comes to this situation)
To sum up, there are two main reasons why app sometimes take a long time to appear in the index:
The building process is slow because we use a new separate virtual machine for every APK
New apps or updates are not published until every build currently queued is complete
I understand it can be frustrating but there is nothing we maintainers can do to manually speed up an important app update.
Of course, if you have ideas on how to improve the building process, your help is welcome.
And app authors that want more control over updates can create their own F-Droid repository.
(Also, keep in mind that we tend to publish updates rather quickly compared to other package managers that build from source like Ubuntu for example.)
Just because I have no idea how f-droid works, why is that? I have a hard time figuring out the rationale behind this choice.
Also IMHO apps building, in addition to fifo, should take into account some kind of priority e.g. (top to bottom): security upgrade, broken app upgrade, standard/new features upgrade. Every time an app is built, the builder should check what the next high priority app is in queue and needs to be built, if any. Just an opinion of an outsider, I don’t know if it’s feasible right now.
Generating the index takes a few hours (fdroid update has to gather all kind of metadata information from all the apps source repos). You can probably imagine why it’s done in batches
This is a very interesting and useful information. I’m sure there’s a bug hanging somewhere for it. Please someone share if not difficult: besides obvious “caching” improvement I got another idea to purpose.