duplicity-team team mailing list archive

[Kenneth Loafman <kenneth@xxxxxxxxxxx>]

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 <lists@xxxxxxxxxxxxxxxxxx> 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
>
>
>
>