On Fri, Nov 9, 2018 at 2:04 PM Graham Leggett <minf...@sharp.fm> wrote:
> On 09 Nov 2018, at 17:51, Stefan Eissing <stefan.eiss...@greenbytes.de> > wrote: > > > So, the chance is high that releases we do will work for most of you. > > AND the chance is high that releases might break something for some of > you (hopefully a few). > > The chance is very low that releases might break something, and this is > done by design. > > The place where we might break something is trunk. Before you get anywhere > near a release, you have to carve out your change, and propose it for > backport to a release branch. This is the first check. Two other people > will then check your backport, and if problems are found you’ll be asked to > fix it. That’s the second and third check. Then a release is proposed. A > tarball is cut, and a whole lot of new people do checks on the tarball. In > the case of 2.4.37, this was the fourth, fifth, sixth, seventh, eighth, > ninth, tenth and eleventh check for the 8 people who tested it. > > This strategy has worked very well for us since the 1990s, and we must not > understate its importance. Good summary, but it's inevitable, Stefan was pointing out that something is likely to break in a feature/enhancement release for *someone*. Not for the vast majority of users who have somewhat stock configurations, but for those with their own custom modules or filters or even build schemas that get touched when we add dependencies and change the influence (not necessarily the definition) of the directives. The goal is to make that number of cases as small as possible, as you've both pointed out. Thanks for the reminder/pointer to the rpm instructions.
