duplicity-team team mailing list archive

[Kenneth Loafman <kenneth@xxxxxxxxxxx>]

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 <kenneth@xxxxxxxxxxx>
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 <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
>>
>>
>>
>>