On Wed, Sep 25, 2019 at 1:56 PM Sasha Litvak
<alexander.v.litvak(a)gmail.com> wrote:
I guess for me the more crucial questions should be answered:
1. How can a busted release be taken out of repos
(some metadata
update I hope)?
It's hard to define the word "busted" in a way that satisfies everyone.
For example, in the past, we've heard rumors that the releases are
"busted" and we need to pull them, and in reality the impact turned out
to be way smaller than expected. If we let panic reign, we would have
builds appearing and disappearing quite often.
Or to borrow a real example, what happens when the new (buggy) release
fixes a CVE, and we coordinated the disclosure of the CVE to happen on
release day? Then we're hurting some users to help others.
2. Can some fix(es) be added into a test release so
they can be
accessed by community and tested / used before next general release
is avaialble. I was thinking about trying to pick some critical
backports for internal build / testing but it is not very simple for
everyone. It seems that shaman has some test builds going on, so may
be if a track issue will mention that build xxxyz contains fixes for
ticket 9999 "for testing purposes only use at your peril", it will
allow the community to test the build and for someone who in need to
get to the higher ground quickly.
There's certainly more to explore here. Maybe we need a defined release
criteria so things are less subjective. Or maybe increasing the
frequency and decreasing the size of releases will help. I'm interested
in lowering the barriers for contributors to test early and often so
our cutting-edge users get their builds fast and our more conservative
users get something more stable.