On Wed, Sep 25, 2019 at 1:56 PM Sasha Litvak <alexander.v.litvak@xxxxxxxxx> 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. _______________________________________________ ceph-users mailing list -- ceph-users@xxxxxxx To unsubscribe send an email to ceph-users-leave@xxxxxxx
 |