and while this autoupdating may be nice, it is really risky for production
systems. so once again. let's adopt snap versioning like blender does it (see
below and https://snapcraft.io/blender).
let's keep 'latest/{stable..edge}' but additionally push at least
'<version>/stable', so users can decide to (re)install fixed versions too.
makes downgrading in case something goes wrong so much easier.
:$ snap info blender
name: blender
summary: Blender is the free and open source 3D creation suite.
SNIP
channels:
latest/stable: 3.1.0 2022-03-09 (1925) 225MB classic
latest/candidate: ↑
latest/beta: 3.1.0 2022-02-11 (1731) 226MB classic
latest/edge: ↑
3.1/stable: 3.1.0 2022-03-09 (1925) 225MB classic
3.1/candidate: 3.1.0 2022-03-21 (2020) 225MB classic
3.1/beta: ↑
3.1/edge: ↑
3.0/stable: 3.0.1 2022-01-26 (1653) 223MB classic
3.0/candidate: ↑
3.0/beta: ↑
3.0/edge: ↑
2.93lts/stable: 2.93.8 2022-02-02 (1698) 205MB classic
2.93lts/candidate: 2.93.9 2022-03-21 (2019) 205MB classic
2.93lts/beta: ↑
2.93lts/edge: ↑
2.92/stable: 2.92.0 2021-02-25 (111) 196MB classic
2.92/candidate: ↑
2.92/beta: ↑
2.92/edge: ↑
2.91/stable: 2.91.2 2021-01-20 (65) 193MB classic
2.91/candidate: ↑
2.91/beta: ↑
2.91/edge: ↑
2.90/stable: 2.90.1 2020-11-24 (47) 187MB classic
On 21.03.2022 21:50, Aaron wrote:
Kenneth and team,
On Mon, Jan 13, 2020 at 5:50 AM Aaron <li...@whitehouse.kiwi.nz
<mailto:li...@whitehouse.kiwi.nz>> wrote:
[...]
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.
[...]
On 2020-01-13 17:23, Kenneth Loafman 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 am resurrecting this old thread because it looks to me as though the stable snap
broke again (https://gitlab.com/duplicity/duplicity/-/issues/119
<https://gitlab.com/duplicity/duplicity/-/issues/119> -- it also broke for me,
looks like the last two days and also back on 8 and 9 March, so I suspect rev 243 and
250). I would like to try to do more to help solve this problem, so I am not
criticising -- I know you have asked for help and I have not offered to do any more
and you have been left carrying all the work.
I feel like the "proper" solution here is to add a step to the CI/CD process on
Gitlab to test the snap before it goes to stable. That is a bit awkward as snaps do not
run inside Docker containers, which are what is easiest in Gitlab CI/CD. I will try to
make some time to investigate this -- maybe I can set up a spend-limited Linode API key
and just have it run some smoke tests on the snap as part of a specified release process
or something. To do it all as a pipeline, I think we would have to do the release and
snapping in there as well.
A while back you summarised your build/release process for the list here:
https://lists.launchpad.net/duplicity-team/msg04839.html
<https://lists.launchpad.net/duplicity-team/msg04839.html>
Would you mind please setting out what you do now, including the snapping part?
I see there is a makesnap, testsnap and pushsnap in the tools folder, for
example.
I actually have my main server tracking Release Candidate instead of Stable as
mentioned above, so I likely would have caught this latest issue before it went
to stable if it went into candidate for even a few days before stable. Perhaps,
therefore, until we have something where the snap is tested automatically, we
could go for a putting the snaps in the candidate channel, you could post to
this list and I (or someone else) can do a quick test and give you a +1 before
bumping it into stable? I believe most of the issues we have seen with snaps
mean they are completely broken and not even a duplicity --version works, so
the testing burden should be pretty low. As I say, I have my server on
candidate and it sends me an email if my daily backup job fails, so I should
notice it pretty quickly if there is a broken snap in candidate even if I miss
your email.
Many thanks again Kenneth for all of your work.
Aaron
_______________________________________________
Mailing list: https://launchpad.net/~duplicity-team
Post to : duplicity-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~duplicity-team
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~duplicity-team
Post to : duplicity-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~duplicity-team
More help : https://help.launchpad.net/ListHelp
