Bugzilla

First of all, just to make sure we're all on the same page:

1. by "removing Fennec" we mean cleaning its traces from central, beta and release and keeping it in ESR branch until we have a resolution on its future relationship with Fenix. Correct?

2. IIUC, we now have `ship_geckoview` in central, beta and release where we build, sign and push the artifacts under https://maven.mozilla.org/?prefix=maven2/org/mozilla/geckoview/. By `the Fennec APK will no longer be "the package` you specifically talk about no longer building this `public/build/target.apk` (e.g. in [this task](https://tools.taskcluster.net/groups/TUc-h1EqSWW9mdAXSmvTuw/tasks/dfX86xYCQnSC5NP7LI8VlQ/runs/0/artifacts)). Correct?

If so, I don't think we actually need any replacement. In shipping geckoview, we both sign + beetmove individual files and we no longer use any maven.zip or alike, as you mentioned too. So not building that `target.apk` will presuambly have no effects in Releng ecosystem as it is. But the contrary, we can perform some cleanup which is great.

LATER EDIT: seems like we actually do sign the `apk` with the `autograph_apk_fennec_sha1` format but we never actually ship those in the maven.m.o . The beetmover declarative artifacts (such as [this](https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/taskgraph/manifests/fennec_geckoview.yml)) stands proof as there's no trace of `target.apk` around there. I strongly suspect this was carried over while we did some migration to Autograph earlier this year.

First of all, please bear with me - just to make sure we're all on the same page:

1. by "removing Fennec" we mean cleaning its traces from central, beta and release and keeping it in ESR branch until we have a resolution on its future relationship with Fenix. Correct?

2. IIUC, we now have `ship_geckoview` in central, beta and release where we build, sign and push the artifacts under https://maven.mozilla.org/?prefix=maven2/org/mozilla/geckoview/. By `the Fennec APK will no longer be "the package` you specifically talk about no longer building this `public/build/target.apk` (e.g. in [this task](https://tools.taskcluster.net/groups/TUc-h1EqSWW9mdAXSmvTuw/tasks/dfX86xYCQnSC5NP7LI8VlQ/runs/0/artifacts)). Correct?

If so, I don't think we actually need any replacement. In shipping geckoview, we both sign + beetmove individual files and we no longer use any maven.zip or alike, as you mentioned too. So not building that `target.apk` will presuambly have no effects in Releng ecosystem as it is. But the contrary, we can perform some cleanup which is great.

LATER EDIT: seems like we actually do sign the `apk` with the `autograph_apk_fennec_sha1` format but we never actually ship those in the maven.m.o . The beetmover declarative artifacts (such as [this](https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/taskgraph/manifests/fennec_geckoview.yml)) stands proof as there's no trace of `target.apk` around there. I strongly suspect this was carried over while we did some migration to Autograph earlier this year.

First of all, please bear with me - just to make sure we're all on the same page:

1. by "removing Fennec" we mean cleaning its traces from central, beta and release and keeping it in ESR branch until we have a resolution on its future relationship with Fenix. Correct?

2. IIUC, we now have `ship_geckoview` in central, beta and release where we build, sign and push the artifacts under https://maven.mozilla.org/?prefix=maven2/org/mozilla/geckoview/. By `the Fennec APK will no longer be "the package` you specifically talk about no longer building this `public/build/target.apk` (e.g. in [this task](https://tools.taskcluster.net/groups/TUc-h1EqSWW9mdAXSmvTuw/tasks/dfX86xYCQnSC5NP7LI8VlQ/runs/0/artifacts)). Correct?

If so, I don't think we actually need any replacement, nor any form of packaging. In shipping geckoview, we both sign + beetmove individual files and we no longer use any maven.zip or alike, as you mentioned too. So not building that `target.apk` will presuambly have no effects in Releng ecosystem as it is. But the contrary, we can perform some cleanup which is great.

LATER EDIT: seems like we actually do sign the `apk` with the `autograph_apk_fennec_sha1` format but we never actually ship those in the maven.m.o . The beetmover declarative artifacts (such as [this](https://hg.mozilla.org/mozilla-central/file/tip/taskcluster/taskgraph/manifests/fennec_geckoview.yml)) stands proof as there's no trace of `target.apk` around there. I strongly suspect this was carried over while we did some migration to Autograph earlier this year.