OK, snap is in candidate as 0.8.10.1558. It's been checked with snapcraft.io release-tools.
...Ken On Mon, Jan 13, 2020 at 11:23 AM Kenneth Loafman <[email protected]> wrote: > Aaron, > > I agree with everything you said! > > I'll start pushing to *candidate* instead of *stable* for releases. You > can check it out and promote it to stable. Snaps may lag behind repo > releases, but that's OK. One change I've made is that now snaps are > versioned with the revno of the repo, like 0.8.10rev1548 so we can identify > them better. > > I'm fighting with versioning right now. The source is unversioned in the > repository and I want to change that so that we can track it better. Some > of the package managers for other distro's are not pulling from the release > tarballs, instead pulling from repo and not running *dist/makedist*, so > no version when running '*duplicity --version'* . > > I'm looking at the module *pkg_resources*. It seems a bit heavy, but > it's the module-de-jour for packaging. I hope it has traction. > > Any thoughts? > > ...Thanks, > ...Ken > > > > > > > On Mon, Jan 13, 2020 at 5:50 AM Aaron <[email protected]> wrote: > >> Kenneth, >> >> On 2020-01-09 18:25, Kenneth Loafman wrote: >> >> Gave up and swapped to Python3 for snaps. It works now. >> >> As to what was happening, I don't know, I can't reproduce it. >> >> >> Great that you turned around a fix so quickly. Are we happy enough with >> Python 3 for backends etc that we want to throw that straight out into >> Stable or should we keep stable as the 0.8.08 version while we beta test >> the Python 3 snap? I suppose we've at least had some testing of duplicity >> on Python 3 from the distros dropping Python 2. >> >> If it would be helpful, I would be happy to volunteer to be more involved >> in the testing and release process of snaps through channels to give a >> second pair of eyes/small amount more QA. >> >> We could do something with the snap channels like the following: >> >> 1. Reserve Edge for bleeding edge like automatically created snaps >> from Master. >> 2. You (Kenneth) put new releases into Beta. >> 3. I could run some basic tests (I have the beginnings of some >> scripts that run tests in bare lxc containers to catch missing undeclared >> dependencies etc) and, if all looks good, promote them from Beta into >> Candidate. >> 4. We could leave these sitting in Candidate for at least a week or >> so. If I know these have had some initial tests then I'm happy to switch >> some of my boxes to this track. Hopefully others on the team will, too. >> Then we will catch any major issues (like this) before any Stable users. >> 5. When/If you think appropriate, you can advance any candidates to >> Stable. >> >> Up to you, of course. My intention is to keep you in control of both >> adding new snaps and releasing to stable, but giving one additional set of >> checks/pair of eyes before hitting anyone's production boxes. I think Snaps >> are a great distribution mechanism for us, but it does mean there's no >> distro testing/QA/beta process between us and our users and we need to take >> a bit more of that responsibility. >> >> Thanks for your work fixing this. >> >> Kind regards, >> >> Aaron >> >> >> >>
_______________________________________________ Mailing list: https://launchpad.net/~duplicity-team Post to : [email protected] Unsubscribe : https://launchpad.net/~duplicity-team More help : https://help.launchpad.net/ListHelp
