On 20.08.2019 20:50, Paul Hammant wrote: > My DevOps consulting life (around how to get to Trunk-Based > Development from some often ClearCase inspired branching model), > starts with what release cadence are you at now, and what do you want > to get to. Clients who are quartly want to get to monthly (and have > less unplanned releases following each). Clients that are monthly want > to get to weekly (same elimination on unplanned). Aaand clients that > are weekky eye daily. Sure that's dev teams of 20-1000 in one repo, > where change would firehose into the repo if it could, > > *I've not encountered an enterprise team that wanted to slow down > release cadence.* > > Seems to me Svn's problems are 1) lack of committers, perhaps because > 2) patch contributors don't feel it matches their smoother experience > elsewhere, and because 3) running "the build" from zero is hard, and > 4) tests in the build isn't a super uniform thing. > > If you all developed on trunk (patchsets for trunk, or direct to it), > and had an automated CI build setup that tested all permutations in > parallel, and a merging bot that attempted to cherry-pick commits > marked as [BUGFIX] back to all supported release branches without > human intervention (and Apache-TM votes), then you might have > streamlined things. Such a bot shouldn't shit the bed if the > cherry-pick fails *
Duh. We have all that, except for the automated backport because no-one sane believes the word of *one* person that some [BUGFIX] commit is actually a viable candidate for any particular release branch. This is all documented in our community guide, which you'd be well advised to read before pontificating. -- Brane
