Bugzilla

That might be true overall, but I must insist you are mistaken when it comes to `gecko_taskgraph`, it doesn't have to be like this :)

What you should be depending on are:
https://github.com/taskcluster/taskgraph
https://github.com/mozilla-releng/mozilla-taskgraph

There we take great pains to follow semantic versioning and avoid breaking consumers. Those repos are designed to be used across projects, and you can pin their dependencies to a specific version, so you can deal with breakage on your own terms.

I've scanned the tasks in your repo, and I see you use a lot of similar kinds and are directly using a lot of the `gecko_taskgraph` transforms, especially for release tasks.

The piece you might be missing is that the grand vision is for `mozilla-taskgraph` to house all the common release type tasks, like signing, beetmover, balrog, etc. These are probably less Gecko-specific than you think. Other projects like mozilla-vpn-client also have transforms that deal with stuff like this. So my suggestion if you want to both stop depending on Gecko and not be responsible for maintaining it in the long term? Move it into `mozilla-taskgraph` instead of hard forking. I think you'll find I'll be eager to help, as you'll be helping us create transforms that benefit everyone.

I totally get that this isn't trivial and you have very limited resources to work on it. The good news, is that this is something that can be done gradually over time. So my goal for now is to try and convince you that this is the right approach and help you get started down this path.

p.s You can still use transforms from `gecko_taskgraph`, even if you don't use it as the entrypoint (i.e follow steps 1 and 2 that I outlined in comment 15). This alone should drastically cut back on the amount of breakage you receive from us. So even if you don't want to do any forking, I recommend you at least take those steps.

That might be true overall, but I must insist you are mistaken when it comes to `gecko_taskgraph`, it doesn't have to be like this :)

What you should be depending on are:
https://github.com/taskcluster/taskgraph
https://github.com/mozilla-releng/mozilla-taskgraph

There we take great pains to follow semantic versioning and avoid breaking consumers. Those repos are designed to be used across projects, and you can pin their dependencies to a specific version, so you can deal with breakage on your own terms.

I've scanned the tasks in your repo, and I see you use a lot of similar kinds and are directly using a lot of the `gecko_taskgraph` transforms, especially for release tasks.

The piece you might be missing is that the grand vision is for `mozilla-taskgraph` to house all the common release type tasks, like signing, beetmover, balrog, etc. These are probably less Gecko-specific than you think. Other projects like mozilla-vpn-client also have transforms that deal with stuff like this. So my suggestion if you want to both stop depending on Gecko and not be responsible for maintaining it in the long term? Move it into `mozilla-taskgraph` instead of hard forking. I think you'll find I'll be eager to help, as you'll be helping us create transforms that benefit everyone.

I totally get that this isn't trivial and you have very limited resources to work on it. The good news, is that this is something that can be done gradually over time. So my goal for now is to try and convince you that this is the right approach and help you get started down this path. Then over the course of years, we slowly move logic into either `comm_taskgraph` or `mozilla-taskgraph` (or even the core taskgraph if it's generic enough).

p.s You can still use transforms from `gecko_taskgraph`, even if you don't use it as the entrypoint (i.e follow steps 1 and 2 that I outlined in comment 15). This alone should drastically cut back on the amount of breakage you receive from us. So even if you don't want to do any forking, I recommend you at least take those steps.