New App Merge Queue is not reviewed by anyone?

1

Just wondering, because i see a lot of new app merge requests and they seem not to be reviewed at all.
Asking because there is stated that merge requests are processed within 1-2 days.

2

Here is the thing: one needs to be quite an experienced F-Droid developer to review MRs. This is a very boring business, and experienced folks tend to work on something more fun.

Same thing with broken builds.

3

You mean to check the source code of the app that is submitted?
If not, i donā€™t get. The merge request is a simple addition of yaml file.

4

When I add some app I do selectively check its source code. But this is optional. Compulsory things:

  • License of the app and its dependencies. They all must be a) free, b) compatible with each other (no GPL 2.0 and Apache 2.0 in the same app, for example).
  • Versions of build tools. Google does not publish the source code of prerelease versions of the Android Gradle plugin. Needless to say that only free tools must be used.
  • Blobs. No JARs or native libraries.
  • Versioning. Many devs donā€™t know why versionCode exists.
  • Check autoupdating.
  • Test that the app builds (they often donā€™t).
  • Test that it doesnā€™t crash as hell.

Also there are a plenty of things to do wrong in the metadata file, like misuse of output, confusion between build and prebuild, use of hashes instead of tags, etc.

So thereā€™s some work behind a ā€œsimple addition of yaml file.ā€ You have to do it over and over again, explaining the same things many times to different people. And the worst thing is that a lot of apps are soon abandoned by their authors and nobody is using them. So a lot of your effort is just wasted. Doesnā€™t sound motivating, does it? :slight_smile:

P.S. Looks like a rant, oh well.

1 Like
5

iā€™m very new to f-droid, but it seems to me that CI does pretty much great job on a lot of items from this list. while creating a merge request for my app, iā€™ve came across a lot of things from this list.
btw i donā€™t understand a policy about jar blobs. there is a gradle_wrapper.jar that is created by android studio, and iā€™ve found it in a lot of apps that are present in the repo. is it ok? in my app it is also present, may be i should remove it?
anyways, may be those very experienced devs may implement all of the checks in CI? even license checking is possible in auto mode. there are such things like ā€˜licensedā€™ and ā€˜license-checkerā€™ projects.

6

there is a gradle_wrapper.jar that is created by android studio, and iā€™ve found it in a lot of apps that are present in the repo. is it ok? in my app it is also present, may be i should remove it?

fdroidserver removes Gradle wrapper automatically. Just leave it as is.

anyways, may be those very experienced devs may implement all of the checks in CI? even license checking is possible in auto mode. there are such things like ā€˜licensedā€™ and ā€˜license-checkerā€™ projects.

Everyone is welcome to improve CI and fdroidserver in general. BTW, CI in fdroiddata didnā€™t check app source code at all until recently.

7

Iā€™ll admit I donā€™t always remember to check those two.
I really think they should be handled by the scanner.

8

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.