On Mon, Aug 21, 2023 at 10:32:42AM +0200, Michal Prívozník wrote: > It's been a while since libvirt-snmp was actively developed. Now it > receives only libvirt-ci related commits. The code compiles with > net-snmp-5.9.3 but the freshly released net-snmp-5.9.4 [1] breaks > compilation [2]. Now, libvirt-snmp has this crazy architecture, where > some sources are manually generated from src/LIBVIRT-MIB.txt, then > edited (added code to talk to libvirt) and then added to git. > > This is labor extensive and since I don't think libvirt-snmp is actually > used I'd like to sunset it. According to repology [3] only Gentoo (and > its clones) has the latest version (released ~5 years ago). And I doubt > it has any real users there. > > Thoughts? > > 1: https://sourceforge.net/projects/net-snmp/files/net-snmp/5.9.4/ > 2: https://bugs.gentoo.org/show_bug.cgi?id=912582 > 2: https://repology.org/project/libvirt-snmp/versions > > Michal > Per our private discussion Michal, Peter, and I concluded that archiving the project in GitLab is a harmless operation that can be undone at any point in time, so I went ahead and toggled the flag.

On Tue, Aug 22, 2023 at 12:44:16PM +0100, Daniel P. Berrangé wrote: > On Tue, Aug 22, 2023 at 01:26:47PM +0200, Erik Skultety wrote: > > On Mon, Aug 21, 2023 at 10:32:42AM +0200, Michal Prívozník wrote: > > > It's been a while since libvirt-snmp was actively developed. Now it > > > receives only libvirt-ci related commits. The code compiles with > > > net-snmp-5.9.3 but the freshly released net-snmp-5.9.4 [1] breaks > > > compilation [2]. Now, libvirt-snmp has this crazy architecture, where > > > some sources are manually generated from src/LIBVIRT-MIB.txt, then > > > edited (added code to talk to libvirt) and then added to git. > > > > > > This is labor extensive and since I don't think libvirt-snmp is actually > > > used I'd like to sunset it. According to repology [3] only Gentoo (and > > > its clones) has the latest version (released ~5 years ago). And I doubt > > > it has any real users there. > > > > > > Thoughts? > > > > Per our private discussion Michal, Peter, and I concluded that archiving the > > project in GitLab is a harmless operation that can be undone at any point in > > time, so I went ahead and toggled the flag. > > Yes, archiving is the right thing to do in this scenario, and is trivially > reversed. We've already got a bunch of other archived repos :-) We should clean up the container registry for this and other archived repositories too. I'm betting they take up a non-trivial amount of our group's storage quota for no good reason.

I'm also strongly inclined to archive the following: * libvirt-cim * libvirt-appdev-guide-python * libvirt-publican * libvirt-sandbox * libvirt-sandbox-image * libvirt-designer

On Fri, Sep 01, 2023 at 02:15:59AM -0700, Andrea Bolognani wrote: > On Thu, Aug 31, 2023 at 04:53:47PM +0100, Daniel P. Berrangé wrote: > > I'm also strongly inclined to archive the following: > > > > * libvirt-cim > > * libvirt-appdev-guide-python > > * libvirt-publican > > * libvirt-sandbox > > * libvirt-sandbox-image > > * libvirt-designer > > Sounds good to me. It will save us some effort if we don't need to > keep these repositories up to our standards (mainly in terms of CI) > while they're seeing zero actual development. > Fine by me. If you haven't done so yet, I'll unleash https://gitlab.com/eskultety/gitlab_cleaner to clean the pipelines.