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
Received on 2019-08-20 21:06:21 CEST