I would like to request an ownership transfer of the
archivemail snap to @snapcrafters.
I posted a call for testing a week ago, but no responses yet - unsurprising as it’s pretty niche (and the .deb package still exists in the archive for all Ubuntu series pre-focal).
I have it scheduled to run hourly on my personal machines and haven’t run into any issues at all.
Thanks in advance!
Edit: If this is also the appropriate place to ask a snapcrafters admin to fork the repo into github.com/snapcrafters (and configure the repo for automatic publishing into edge on commit), then please can that be done too? Thanks!
@popey is it ok to transfer this snap to snapcrafters?
@Igor or @Wimpress are best placed to make the decision right now.
Technically, this should not be a problem. @barryprice the only question is whether this tool is expected to receive any functional updates, and whether there could be problems if the mbox format changes - I know there’s an RFC but still - and if it works with the variations of the mbox format?
I don’t expect it to receive functional updates - there hasn’t been a release since 2011, and not even a commit since 2012. So I’m anticipating this being a one-and-done, but obviously can’t guarantee that.
I personally use it with a Maildir setup (coupled with offlineimap), but could certainly set up some tests with mbox setups if that would help.
If you can do some more testing, it would be nice. But overall, I think we can move this to snapcrafters.
Thanks, I’m not sure how much detail you need but I’ve thrown together a bunch of test mail in various mbox formats and haven’t been able to force an error.
Upstream does have a test suite, which I could add as a step to snapcraft.yaml, but it’s relatively limited and doesn’t use real-world data like my own tests did. I don’t recall seeing this approach used with other snaps, but if it’s worth adding I can certainly do so.
For reference, all of the core* snaps when built run
make test from inside the snapcraft.yaml, which may or may not be applicable to your snap, but there is some precedence around snaps self-testing themselves when compatibility and correctness is very important for the snaps and when the snapcraft.yaml enables you to do so (i.e. we can do this for the core* snaps because there we are verifying static content, we don’t need any running services etc. to check, if that were the case we probably couldn’t do the same testing from within the snapcraft.yaml)
I think we can transfer, and then if there are any glitches or problems, we can work together to fix them.