I submitted an app (Meritous) a few years back.
It was removed from the repo a while ago without notification. I can’t find any log of that removal.
When I realized it I updated the package and submitted it (net.asceai.meritous.txt: new version (!3962) · Merge requests · F-Droid / Data · GitLab).
I had to recreate a full build environment and spam my disk space due to not having privs to run on F-Droids’s CI server (?).
I had to circumvent bugs introduced by the way F-Droid fiddles with local.properties.
At last it compiles but I’ve been pinging for a month and only got silence.
There seem to be other applications that are updated regularly in the repo, so I assume there’s bad luck here, but this is getting ridiculous.
My bet would be that it was (automatically?) moved to the archive due to inactivity.
When I submitted my application, everything went very smooth for the most part. I think it heavily depends on the complexity of the build, whether you’ll have a pleasant experience or not
Looking at the inclusion request you opened, its a pity that you did not get more feedback, but I guess the FDroid team is small and has limited resources at hand.
However, its nice to see, that in the end the build seems to pass What you could do now is squash your commits into one, to keep the history clean
Hi vanitasvitae.
(I don’t care much why it was removed but I hope I’ll be notified next time. The game works so I won’t rebuild it just to make people waste bandwidth on a non-update :P)
There is already one single commit.
We are only a handful of volunteers reviewing merge requests and RFP so unfortunately it is common for app inclusions and manual updates to take several weeks.
(Contributions are of course very welcome.)
However, a lot of apps have auto update enable so news releases are built and published automatically a few days after they are published upstream.
I see. Did you consider doing something like e.g. Fedora where once an app is first validated, the maintainer can update it without a new review?
The “auto update” mode sounds nice but will require a full new review anything there’s a change in the build process.
Given @beuc’s work on Android SDK Rebuilds, I think he qualifies for a more rapid inclusion as an F-Droid contributor. @beuc the process starts with opening a new issue on the fdroid/admin tracker requesting access.
Thanks @Rudloff and @hans.
I think my contributions in app packaging and in the base SDK are different so I didn’t want to use my foot in one to gain foot in the other
However if you think I’ll need access to further the work/integration on android-rebuilds (say, if we expect a couple patches to fdroid-server), I can request access.
One of the essential things about reviewing new maintainers is finding
evidence of their commitment to free software and privacy. Your Android
Rebuilds and Debian work show that you are clearly committed to Free
Software. So yes, that experience really is directly relevant and related.
What you could do now is squash your commits into one, to keep the history clean 