3 ms·

Sometimes it’s still hard to tackle people psychology who are used to “comfort” of the “sta[b]le” branches. So at work I came up with the following observation

by ay 2y ago

Sometimes it’s still hard to tackle people psychology who are used to “comfort” of the “sta[b]le” branches. So at work I came up with the following observation: if you are a consumer and are afraid of unpredictable events at head of master/main branch - if you use the head of master/main from 21 days ago, you have 3 weeks of completely predictable and modifiable future. Any cherry picks made are made during the build process, so there is no branch divergence - if the fix gets up streamed it is not cherry picked anymore. Thus, unlike with stable branches, by default it converges back to master. “But what if the fix is not upstreamed ?” - then it gets to be there, and depending on the nature of the code it bears a bigger or smaller ongoing cost - which reflects well the technical debt as it is. This has worked pretty well for the past 4-5 years and is now used for quite a few projects.

bongodongobob 2y ago
This is how OS updates have worked at every company I've been at. Either have a handful of devices that get them immediately and you scream test, or you simply just wait 3 weeks, then roll them out. (Minus security CVE's of course)
- ay 2y ago
  Lucky you! :-) The one additional bonus of this scheme that popped up somewhat as a side effect is one can deploy the new feature into the “prod” build even before it hits the master: code it up, add the instruction to cherry-pick the change into the branch of a builder, test it and if it works then merge that instruction into the “master” builder. Then, the feature will remain in prod builds as a custom cherry-pick until it’s merged upstream. And if it isn’t merged - then one has a recurring reminder of their technical debt that they have incurred by diverging. Once adopted, it became a pretty cool way to adopt “right” long term incentives without door-stopping the short term “urgent” deliverables.

by ay 2y ago

bongodongobob 2y ago

This is how OS updates have worked at every company I've been at. Either have a handful of devices that get them immediately and you scream test, or you simply just wait 3 weeks, then roll them out. (Minus security CVE's of course)

ay 2y ago
Lucky you! :-) The one additional bonus of this scheme that popped up somewhat as a side effect is one can deploy the new feature into the “prod” build even before it hits the master: code it up, add the instruction to cherry-pick the change into the branch of a builder, test it and if it works then merge that instruction into the “master” builder. Then, the feature will remain in prod builds as a custom cherry-pick until it’s merged upstream. And if it isn’t merged - then one has a recurring reminder of their technical debt that they have incurred by diverging. Once adopted, it became a pretty cool way to adopt “right” long term incentives without door-stopping the short term “urgent” deliverables.