Recently a "non-responsive" process for one of the go-sig members, made a lot of go-sig packages orphans.

Uhm ... sorry about that? :grimacing:

Earlier Mikel Olasagasti sent an email to devel explaining the current situation.

I was wondering what our solutions to this problem could be. I don’t mind adopting a significant amount of packages like Mikel did, but I want to evaluate what are the possibilities here before adopting hundreds of packages.

Is there a way to make the Go SIG group owner so we can stop the orphaning process? I don’t think so based on how Bugzilla works.

This is not possible in our current system - packages need a non-group "main admin". The closest you can get to "group owned" is for a go-sig member to adopt the package, add "@go-sig" group with "commit" or "admin" privileges (if it isn't there already), and set default bugzilla assignee overrides to "@go-sig" as well (there's APIs to do both things, so it would even be scriptable).

This is not possible in our current system - packages need a non-group "main admin". The closest you can get to "group owned" is for a go-sig member to adopt the package, add "@go-sig" group with "commit" or "admin" privileges (if it isn't there already), and set default bugzilla assignee overrides to "@go-sig" as well (there's APIs to do both things, so it would even be scriptable).

So if we follow that approach, and I understood you correctly, when a new bug is submitted against a given package, the @go-sig (aka all of the users in that group) will get notifications? My main concern is that, if someone in the SIG takes a significant amount of packages, they might be overwhelmed in the long run.

So if we follow that approach, and I understood you correctly, when a new bug is submitted against a given package, the @go-sig (aka all of the users in that group) will get notifications? My main concern is that, if someone in the SIG takes a significant amount of packages, they might be overwhelmed in the long run.

Yes, but this should already be the case - since go-sig group is co-maintainer on all golang-* packages, and co-maintainers are already CC'd on all bugs for these packages.

EDIT: Some members might not be getting notifications either way, if they are not subscribed to the group-internal bug-mailing-list - for them, nothing will change.

What sort of technical work needs to be done to make it possible for a SIG to be the main admin? My guess is that there may be some unanticipated downsides to have one person be the main admin for thousands of packages. For example, I think this would effectively make the package dashboard unusable for them.

What sort of technical work needs to be done to make it possible for a SIG to be the main admin? My guess is that there may be some unanticipated downsides to have one person be the main admin for thousands of packages. For example, I think this would effectively make the package dashboard unusable for them.

The Packager Dashboard already has an option to hide packages where the current user is main admin but they're also part of a group, so this shouldn't be an issue. For example, I'm main admin for 4-digit-number of Rust packages, but I can easily hide them from my dashboard.

Thanks a lot for the clarifications. Is there a place where I can look into how to automate in case we want to adopt them all?

I don't know if the API behind the "Take" / unorphan button is documented, and I know that the "set bugzilla assignee" API is undocumented (because it's part of pagure-dist-git, not pagure proper) .. but the "add a group" API is documented here:

https://src.fedoraproject.org/api/0/#projects-tab (under "Modify ACLs on a project")

You might find https://pagure.io/fedora-sig-onboard useful for this (either directly, or to crib logic from).

If the plan is to adopt packages "massively", I'll recommend just to focus on some of the binaries that we want to keep and their deps.

go-sig has the following packages that contains at least one binary:

https://pagure.io/GoSIG/go-leaves/blob/main/f/binaries

The main question would be what we want to maintain.

There are some packages like golang-vitess or golang-github-cockroachdb-pebble that I believe no-one are using, as they're outdated and adopting them or their required deps will just make them agonize a bit more.

Some other packages are already in orphan mode (and even in FTBFS). If no one claims them before the mass retirement that will happen on the 22th of July then I guess they should be retired.

For packages with binaries that have a maintainer (clash, gopass, dnscrypt-proxy, ...) but required deps are orphaned, maybe we can contact them and wait for some feedback. If they want to keep they could adopt the rest of the packages or ask "go-sig" to adopt them. If they've no interest I'll just let the packages be retired after the mass retirement.

What I'm doing is slowly checking the binary packages I maintain (gh, glab,xq, ...) and adopt their direct deps and some remote deps. I already adopted +150 packages, but a lot of packages are still pending with complex stacks like docker, prometheus or the whole grpc/proto packages pending. If I'm not able or someone else is not able to adopt the remaining deps, then go-sig adopting them could be useful to keep maintained packages alive.

That sounds like a good way forward to me. I've been trying to do a similar thing with Rust packages (i.e. drop outdated / unused / leaf libraries, orphan outdated applications).

Not sure if this is the best way to do it, but "It works :registered: "

https://github.com/alexsaezm/dotfiles/blob/main/scripts/.local/scripts/fedora-adopt-packages

Just in case someone else need it.

So… what's the status? How many packages still need to / should be adopted?

So… what's the status? How many packages still need to / should be adopted?

At this moment, 727 packages are still marked as orphaned or orphan impacted.

Of those 727 packages 91 are packages that are owned by orphan that have a binary:

aerc
golang-ariga-atlas
golang-contrib-opencensus-resource
golang-github-acme-lego
golang-github-ajstarks-deck
golang-github-akavel-rsrc
golang-github-appc-docker2aci
golang-github-appc-goaci
golang-github-appc-spec
golang-github-bifurcation-mint
golang-github-boltdb-bolt
golang-github-burntsushi-xgb
golang-github-c-bata-prompt
golang-github-chai2010-gettext
golang-github-chris-ramon-douceur
golang-github-client9-plaintext
golang-github-cockroachdb-pebble
golang-github-coredns-corefile-migration
golang-github-cucumber-godog
golang-github-dave-jennifer
golang-github-docker-slim
golang-github-elazarl-bindata-assetfs
golang-github-emersion-smtp
golang-github-euank-kmsg-parser
golang-github-evanw-esbuild
golang-github-francoispqt-gojay
golang-github-fvbommel-util
golang-github-geertjohan-rice
golang-github-gobuffalo-here
golang-github-gocolly-colly-2
golang-github-google-jsonnet
golang-github-google-wire
golang-github-googlecloudplatform-cloudsql-proxy
golang-github-gorhill-cronexpr
golang-github-gucumber
golang-github-hashicorp-consul-migrate
golang-github-hpcloud-tail
golang-github-in-toto
golang-github-instrumenta-kubeval
golang-github-j-keck-arping
golang-github-krishicks-yaml-patch
golang-github-ledisdb
golang-github-leveldb
golang-github-markbates-pkger
golang-github-mmarkdown-mmark
golang-github-multiformats-multibase
golang-github-mvo5-uboot
golang-github-oklog
golang-github-oneofone-xxhash
golang-github-opencontainers-runtime-tools
golang-github-pact-foundation
golang-github-pierrre-geohash
golang-github-posener-complete-2
golang-github-pquerna-ffjson
golang-github-prometheus-prom2json
golang-github-prometheus-tsdb
golang-github-quay-goval-parser
golang-github-rakyll-statik
golang-github-rwcarlsen-goexif
golang-github-shopify-toxiproxy
golang-github-sourcegraph-syntaxhighlight
golang-github-spyzhov-ajson
golang-github-stomp-3
golang-github-twpayne-waypoint
golang-github-uber-athenadriver
golang-github-vmware-govmomi
golang-github-xo-terminfo
golang-github-xordataexchange-crypt
golang-github-yuin-gopher-lua
golang-github-zmap-zlint
golang-gitlab-commonmark-linkify
golang-gopkg-neurosnap-sentences-1
golang-gvisor
golang-jaytaylor-html2text
golang-k8s-apiextensions-apiserver
golang-k8s-code-generator
golang-k8s-kube-aggregator
golang-k8s-pod-security-admission
golang-k8s-sample-apiserver
golang-k8s-sample-cli-plugin
golang-modernc-golex
golang-modernc-lex
golang-sigs-k8s-kustomize
golang-sourcegraph-appdash
golang-vitess
jid
kiln
micro
powerline-go
wgctrl

So in case no-one adopts them all those packages will go away in 12 days.

Then there are still a bunch of binary packages affected by orphans like vgrep, bettercap, cadvisor, gmailctl, gopass or powerline-go.

As I don't know if there is any good way to list which packages with binaries are affected by orphans, would contacting all the maintainers from go-sig that have a package with a binary to check the dashboard?

git clone https://pagure.io/GoSIG/go-leaves
cd go-leaves
curl https://pagure.io/fedora-misc-package-utilities/raw/master/f/find-package-maintainers | python3 - binaries > binaries-by-maintainer
cat binaries-by-maintainer |awk '{print $1}' |grep -v ^orphan

That would be 128 maintainers.

If that's OK, who should contact them?

@gotmax23++ created the file with binaries affected by orphans:

https://pagure.io/GoSIG/go-leaves/blob/main/f/binaries-orphan_affected

grep -v ^ERROR binaries-orphan_affected | python3 find-package-maintainers - > binaries-orphan_affected-by-maintainer

There are 40 maintainers in the list.

If no one complains I'll send an email to each maintainer using fas@fedoraproject.org with the following text:

[URGENT ACTION REQUIRED] Fedora go package affected by orphan
Hi,
I'm contacting you as the maintainer of one or more packages listed in this file:
https://pagure.io/GoSIG/go-leaves/blob/main/f/binaries-orphan_affected
Some of the dependencies of your package are in Orphan mode and will be removed in 9 days. This will make your package unable to be built and, eventually, retired from Fedora.
Please, check your Packager Dashboard to have more information about the dependency chain:
https://packager-dashboard.fedoraproject.org/
What would be required is required orphan packages to be adopted or to orphan the main package if you don't plan to maintain it.
More information at https://pagure.io/fesco/issue/3017

Looks good to me! I hope this can be resolved :(

Not that my opinion matters that much but thank you very much! I really like it! and thanks to @gotmax23 for the work too!

Hey all,
I'm the maintainer of obfs4 package, which depends on 3 orphaned packages. However, fortunately, the latest version of this package doesn't require any of them, so I won't adapt the dependencies. I'm just waiting for the new dependency[1] package review to be finished so that I can build the latest version. So, I would neither adapt dependencies nor orphan the main package :P

[1] https://bugzilla.redhat.com/show_bug.cgi?id=2221411

aerc
jid
kiln
micro
powerline-go
wgctrl

have been retaken.

I have updated aerc today. I have taken direct dependencies as well, however i don't know well the dependency tree.

Based on the latest update by go-leaves scripts, there are no binary packages affected by orphans after Eclipseo took all the remaining required packages.

https://pagure.io/GoSIG/go-leaves/c/75a61a6834a8572655572dc09fd68bfac3433dd0?branch=main

Dashboard shows 284 packages orphaned or affected by orphans, but may be lower after a new refresh.

I, personally, would have let some of the packages go, as they've not been updated for +2 years and I feel they're hardly used, but great to see someone wants to keep them around.

Yeah so I have been looking up for the dependencies needed to keep our binaries packages working since Sunday, I then extracted the source packages names and looked for the orphaned ones. I injected this this morning into a fetch request to adopt them. I haven't seen the result yet because I needed to get to work.

I know there are a couple that have retired that I need to look up this evening. And I need to check if other binary packages have been orphaned.

The reminder which has not been adopted will go to /dev/null with no bad consequences in theory.

~230 orphan packages were retired yesterday and it seems nothing big has broken.

This doesn't mean go-sig is healthy, as there are multiple software stacks that are in need of updates, but we're in better shape than 2 months ago I would say.

Is there anything left to do with for this ticket, or can we close it?

Let's close this. Whatever additional actions should have been taken, it's too late for them now.