For you Owners, though, it would be easiest if you just made the commit and immediately pushed to edge
so people wanting the latest release (regardless of potential snap stability issues) can get it and people can get testing so we can push it to stable
.
Fair, what’s your definition of ‘a good shake’? If we require an ‘it works OK’ message from someone (or more than one person) before pushing out of edge
people could be waiting indefinitely for a release… But maybe that is the way forward, people wanting a release faster can install the edge
snap and test it. But it would just be good to have a set process for releases rather than the current uncertainty over what we do to get new releases out. Should there be a minimum period for testing? How many a-ok’s do we need before promoting the snap? What do we accept as an a-ok, how comprehensive a test?
Ideally we should be writing automated tests for the snaps, if they pass the tests we should be able to bump them up the channels pretty fast (but we need to determine how fast for all of these cases). Indeed, this is what snappy currently expects upstreams to do given that automatic refreshes are obligatory. We’re not an upstream, but if we wanted to speed up releases I guess we’d have to find or make some automated tests to run, which would be time-consuming (I don’t have the time) and requires expertise in that area. So that’s the ideal case. In practice we’ll just need to ask real people to test snaps and lay out how we’re going to promote snaps on the basis of that.
OK, so I guess, from now on, we need to post a call for testing when a new stable release hits edge
?