I had initially reached out to the individuals listed above in the X-
Debbugs-CC header on December 8, but have not heard anything in reply.
So, I'm opening this bug and including the content of the message I
sent. The only update I have seen since the 8th was bug #1000979 being
ACK'ed by Michael Vogt.
-----

Dear Maintainer, Uploaders, and NMUers,

  I do not personally use snaps, but recently I was updating a golang
library, and snapd was a rdep that I wished to rebuild locally to help
ensure updating the library in unstable wouldn't cause a build failure
for snapd. As I have looked at the state of the snapd package in
Debian, I have become concerned that in its current state, snapd should
not be included in Debian. snapd is quite popular (popcon reports ~13k
installs), and since we're early in the bookworm development cycle, I
hope this package can get cleaned up so it's in good shape for the next
Debian release.

  Specific concerns that I have observed:

  * The most recent commit in the snapd salsa repository, which is
pointed to by the package's d/control file, was on April 6, 2020.
However, new versions of this package have continued to appear and been
uploaded to the archive; where is the git repo for snapd's packaging
being maintained?

  * snapd 2.37.4-1 was the last upload (February 28, 2019) to the
archive by a Maintainer/Uploader. All subsequent uploads to unstable
have been by Michael Vogt, who is _not_ listed as a
Maintainer/Uploader, and doesn't appear to be following the proper NMU
process.

  * An outstanding FTBFS bug (#997257) has been open since October 23rd
of this year, and has yet to receive an acknowledgment.

  * The last d/changelog entry by a Maintainer/Uploader was July 27,
2020. Since August 2020, only Michael Vogt and Ian Johnson have been
making release entries which seem to solely consist of copy-and-paste
upstream release changelogs.

  * No care seems to have been recently given to reported lintian
errors/warnings, an ancient Standards-Version, dependency on an old
version of the `golang` package, etc.

  * Several outstanding bugs are in the BTS with no interaction from
snapd's Maintainer or Uploaders, either in bug reports or via
d/changelog entries. (One bug was just closed in 2.51.7-2, but I have
to go back to January 9, 2018 to find the next bug closed by a new
release of snapd.)

  * d/rules is _ugly_. (Admittedly, this is a subjective call, but it
could be greatly cleaned up and "un-Ubuntued" by removing logic that
don't have anything to do with Debian.)

Sincerely,
Mathias

Thanks for reaching out and reporting this bug. Fwiw, I did reply to the original mail too bug for some reason it seems that the reply did not made it to you, not sure what happened here, sorry for that.

I am preparing an upload of the latest 2.54.1 release of snapd that partly addresses the points you raised. Unfortunately I won't be able to fix it all in this upload (time constraints) but it should improve the situation quite a bit.

Thanks,
 Michael

  There was something weird with me not receiving Michael's initial
reply. I did review my server's logs, but didn't see anything
indicating what the problem was. I do want to include his reply, so
others who see this bug can have the whole context:

  Based on Micahel's comments, it sounds like a couple actions could be
taken that would help more accurately reflect snapd's current state:

  * Formally ping the package maintainer/uploaders (who I haven't seen
any replies from) to ask about filing a RFH/RFA bug against snapd.

  * Also ask them about moving the snapd package into the go-team's
group on salsa, and putting the package under team maintenance. That
would make it a lot easier for individuals to make updates without
stepping on toes.

  Overall it sounds like snapd needs a new maintainer with the time and
interest to maintain the package. As I said, I don't use snaps, and I
don't want to take on packages that I don't actually use. And Michael
sounds pretty busy; I think it may almost be worse to have a barely-
maintained package than an unmaintained one.

Mathias