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:
> On Wed, Dec 08, 2021 at 02:01:03PM +0100, Michael Vogt wrote: > [..] > > 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? > > > I always push my commits to https://salsa.debian.org/mvo/snapd but > indeed I failed to do MR against the main repo. Sorry for that. I > added it now. > > I was mostly working in my "mvo" area because I was not intending to > become the maintainer and just help out but it seems like it's best > if > I get more involved - unless someone else is interested of course :) > > > > > * 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. > > > Indeed, see above, I mostly just wanted to help a bit and did not > want > to step on toes by adding myself but I think I should probably be at > least in the Uploaders field. > > > > > * An outstanding FTBFS bug (#997257) has been open since October > 23rd > > of this year, and has yet to receive an acknowledgment. > > > Sorry again, I will have a look. I was planning to do a new upload to > Debian with the latest snapd release anyway before 2021 ends and > there > I can tackle this. > > > > > * 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. > > > I'm not 100% up-to-date with the latest recommendations around > changelogs, I'm happy to avoid using the upstream changelog and just > do the debian specific bits. Is that the right approach? > > > > > * 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. > > > That is unfortunately correct, as part of this new release I can try > to address it too. Note that the upstream snapd project defaults to > fairly old golang releases because they want to be compilable on > older > distros too but of course there is no need to enforce this on debian. > > > > > * 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.) > > > Indeed, it's a valid concern, I did not pay enough attention there. > But then I also just wanted to help a bit with the releases and not > intended to fully take over maintenance. But it seems I need to try > to > also help more in this area. > > > > > * 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.) > > > Heh :) it is a ugly - it's mostly like this for pragmatic reason, > there is a debian/rules file in the main tree of snapd so it's > easiest > to keep the delta small to make syncing changes back easy. But maybe > it's the wrong trade-off? > > Any help here is welcome btw (from anyone in the CC). I'm a bit rusty > with the latest Debian policy and my day-job is quite demanding > > Cheers, > Michael 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
signature.asc
Description: This is a digitally signed message part
